SIMULATION METHOD AND APPARATUS FOR USE IN ENTERPRISE 

CONTROLS 



COPYRIGHT NOTIFICATION 

[0001] Portions of this patent application contain materials that are subject to 

copyright protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document, or the patent disclosure, as it appears in the Patent and 
Trademark Office. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0002] This is a continuation of US patent application No. 10/304,190 which was 

filed on November 26, 2002 and is titled "Diagnostics Method and Apparatus For Use With 
Enterprise Controls" which was a continuation of US patent application No. 09/410,270 
which was filed on September 30, 1999 which issued on April 29, 2003 as US patent No. 
6,556,950 and is also titled "Diagnostics Method and Apparatus For Use With Enterprise 
Controls". . 

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 

DEVELOPMENT 
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BACKGROUND OF THE INVENTION 

[0004] This invention generally relates to improvements in computer systems, and 

more particularly, to system software for managing the design, simulation, implementation 
and maintenance of a manufacturing process. 

[0005] A visit to virtually any modern manufacturing facility in the world leaves 

room for little doubt that assembly and machining lines have become an integral part of the 
manufacturing process. Robots, computers, programmable logic controllers, mills, drills, 
stamps, clamps, sensors, transfer bars, assemblers, etc., are more numerous than people in 
most modern manufacturing facilities. This is because almost every industry has recognized 
that use of automated assembly and machining lines to form and assemble product 
components and assemblies reduces manufacturing time, reduces product costs and increases 



product quality. Hereinafter, automated assembly and machining will be referred to 
collectively as automated manufacturing. 

[0006] Unfortunately, while automated manufacturing has a large number of 

advantages, such manufacturing also has a number of shortcomings. In particular, the 
process (hereinafter "the development process") of designing, constructing and debugging a 
manufacturing process has a large number of shortcomings. To understand the shortcomings 
of the development process, it is helpful to consider an exemplary development process. To 
this end, an exemplary development process will be described in the context of developing a 
manufacturing line for producing a basic automobile door frame assembly (i.e. the door 
without the window, window motors, activation buttons and other trim components). 
[0007] To this end, initially a body engineer designs a door assembly based on 

experience of parts, structural knowledge and welding information. To facilitate the door 
frame design process a body engineer typically uses a standard computer aided design (CAD) 
package (e.g. CATIA, Pro-Engineer, etc.). Using such a package the body engineer can 
change frame dimensions, component thicknesses, rivet numbers, angles, the shapes of 
curved surfaces and so on. 

[0008] A. The Development Process 

From beginning to end, including the skills of a body engineer, the development 
process required to design, build and debug an automated manufacturing line involves no less 
than four separate engineering disciplines, each of which has a different set of required 
engineering skills. The three disciplines in addition to body engineering include process 
engineering, mechanical engineering, controls engineering and manufacturing engineering. 
[0009] Once the door frame assembly has been designed, the frame design 

information is given to a process engineer. The process engineer designs a process which 
will be required to manufacture the door frame assembly. To this end, the process engineer 
translates management numbers for finished door frame assemblies into a high-level process 
of actions and resources based on acquired experience. When specifying the high-level 
process the process engineer specifies required manufacturing tools (e.g. robots, clamps, 
workcells, etc.). 

[0010] This tool defining process, like the door frame design process, has been 

streamlined by use of computer aided manufacturing (CAM) software packages which enable 
a process engineer to virtually specify different mechanical tool types and tool configurations 
including clamps, robots, mills, drills, assemblers, etc. which can be used to actually 
manufacture the door frame assembly. Sometimes a tool library will be provided in a CAM 
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package which includes commonly used mechanical tools, the mechanical tools selectable for 
reuse when required. Where a required tool is not provided in a library, the CAM package 
and or CAD package can be used to design the required mechanical tool for use in the door 
frame manufacturing process and for storage in the library for subsequent use if desired. 
[001 1] In addition to specifying the mechanical tools, the process engineer may also 

specify mechanical tool movements required during the manufacturing process. For 
example, for a clamp, the process engineer may specify an open position and a closed 
position and thereby may define a range of movements therebetween. This ability to specify 
tool actions allows a process engineer to build a model of a mechanical tool in software such 
that the model has both static and kinematic characteristics. The virtual tool can then interact 
with other parts in an automated virtual manufacturing process in the time dimension. 
[0012] Moreover, the process engineer also specifies mechanical tool timing and 

sequencing via either a bar chart timing diagram, a flow chart or some other suitable 
sequence specifying tool. This sequencing information indicates the sequence of tool 
movements during the automated manufacturing process. Furthermore, the process engineer 
specifies resources and goals to drive the manufacturing process and may attempt to generate 
a cost justification for the frame assembly manufacturing process. 

[0013] Hereinafter, the term "mechanical resources" will be used to refer generally to 

the manufacturing tools which are specified by a process engineer and the specified tool 
movements will be referred to as "behavior". In addition the information as a whole provided 
by the process engineer will be referred to as "process information". 
[0014] Next a control engineer receives the process information and, based on 

experience, uses the process information to select control mechanisms and determines how to 
configure the mechanisms for controlling the mechanical resources. The control system 
includes at least one PLC (i.e. a controller), sensors and actuators and electrical lines and 
hydraulic tubing for linking the PLC to the actuators and sensors. The actuators and sensors 
are control mechanisms. 

[0015] The actuators are eventually linked to the mechanical resources for motivating 

the mechanical resources in a manner consistent with the process information. Sensors are 
eventually linked to mechanical resources or are positioned adjacent mechanical resources 
and indicate an instantaneous condition (e.g. the position of a resource, the temperature of a 
liquid, the position of a work item - the upper left corner of a door frame, etc.) in the 
manufacturing process. 
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[0016] In addition, the control engineer has to integrate the mechanical sequencing 

information, causal relationships, a Human Machine Interface (HMI), I/O tables and safety 
and diagnostic information into the control system design. To aid in the process of selecting 
and configuring control devices to control the mechanical resources and to provide a blue 
print for subsequent assembly of the control system, the control engineer also generates a 
control system schematic with representations of each control device and electrical and 
hydraulic links between devices and the PLC. Hereinafter the information provided by the 
control engineer will be referred to as "controls information". 

[0017] Next, a manufacturing engineer receives the controls information and the 

process information, uses the process information to construct the line via specified 
mechanical resources, uses the controls information to construct the control system and links 
the control system to the mechanical resources. 

[0018] After the line is completely developed, the control engineer further generates 

execution code to execute on the PLCs to implement the automated manufacturing processes. 
Then a control engineer performs tests on line tools to identify execution code bugs in the 
system design. For example, the control engineer may check to determine if a robot arm will 
crash into a work item on a transfer bar during a specified tooling process or if a sensor is 
operating properly to detect the presence of a clamp during a clamp extending movement. 
While an engineer other than the control engineer may be able to debug specific systems, in 
most cases the control engineer is required for the debugging process. This is because any 
change in the system may ripple through other parts of the control process which are not 
intuitive and which may only be known to the control engineer. In most cases many bugs 
show up during this debugging process and therefore this step in the automated 
manufacturing process is extremely tedious. This is particularly true in automated 
manufacturing which requires complex control systems. 

[0019] Hereinafter, the separate sub-processes of the development process which are 

performed by the separate engineers will be referred to as "process phases". 
[0020] B, Development Process Shortcomings 

The above described development process has a large number of shortcomings. First, 
the development process is extremely time consuming. In fact, the typical time required for 
designing, building, testing and reworking a simple manufacturing line is often months and 
the time required for a relatively complex line often takes years of man hours. In many 
industries the import of time is exacerbated by competitive product cycles where getting a 
new product to market before a competitor is crucial to a companies competitive posture. For 
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example, in the automotive industry fresh styling is extremely important to entice product 
turnover. 

[0021] Second, while some of the development process phases have been streamlined 

using design software (e.g. CAD and CAM are used to design a door frame assembly and the 
mechanical tools required to construct the frame assembly), other process phases are not 
streamlined. This is particularly true of the PLC logic programming process. 
[0022] While the industry is starting to employ various programming languages, most 

industrial PLCs are still programmed in Ladder Logic (LL) where instructions are represented 
graphically by "contacts" and "coils" of virtual relays connected and arranged in ladder-like 
rungs across power rails. LL, with its input contacts and output coils, reflects the emphasis in 
industrial control on the processing of large amounts of input and output data. 
[0023] LL also reflects the fact that most industrial control is "real time"; that is, an 

ideal industrial controller behaves as if it were actually composed of multiple relays 
connected in parallel rungs to provide outputs in essentially instantaneous response to 
changing inputs. Present industrial PLCs do not, in fact, employ separate parallel relay-like 
structures, but instead simulate the parallel operation of the relays by means of a conventional 
Harvard or Von Neumann-type computer processor which executes instructions one at a time, 
sequentially. The practical appearance of parallel operation is obtained by employing 
extremely fast processors in the execution of the sequential control program. 
[0024] As each rung is executed, inputs represented by the contacts are read from 

memory (as obtained from inputs from the controlled process or the previous evaluation of 
coils of other rungs). These inputs are evaluated according to the logic reflected in the 
connection of the contacts into one or more branches within the rungs. Contacts in series 
across a rung represent boolean AND logic whereas contacts in different branches and thus in 
parallel across a rung represent boolean OR logic. 

[0025] Typically a single output coil at the end of each rung is set or reset. Based on 

the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a 
bit (which ultimately becomes an output to the industrial process or to another LL rung). 
[0026] Once a given rung is evaluated the next rung is evaluated and so forth. In the 

simplest form of LL programming there are no jumps, i.e. all rungs are evaluated in a cycle or 
"scan" through the rungs. This is in contrast to conventional computer programming where 
branch and jump instructions cause later instructions or groups of instructions to be skipped, 
depending on the outcome of a test associated with those branch or jump instructions. 
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[0027] While LL is well suited for controlling industrial processes like those in the 

automotive industry, LL programming is not an intuitive process and, therefore, requires 
highly skilled programmers. Where hundreds of machine tool movements must be precisely 
synchronized to provide a machining process, programming in LL is extremely time- 
consuming. The time and relative skill associated with LL programming together account for 
an appreciable percentage of overall costs associated with a control system. 
[0028] Industry members have made several attempts to streamline the logic 

programming process. One way to streamline any type of programming is to provide 
predefined language modules, expressed in a language such as LL, which can be used 
repetitively each time a specific function is required. Because of the similar types of tools 
and movements associated with different mechanical tools, industrial control would appear to 
be an ideal industry for such language modules. 

[0029] The predefined logic module approach works quite well for certain 

applications, like small parts-material handling or simple machining. The reason for this is 
that the LL required for these applications tends to be very simple. In small parts material 
handling applications the I/O count is low and the interfaces between modules are minimal. 
In fact, the mechanisms are often independent units, decoupled from neighboring 
mechanisms by part buffers such that no signals are required to be exchanged between 
modules. These "loosely coupled" systems lend themselves to "cut and paste" programming 
solutions. 

[0030] Unfortunately the predefined, fixed logic module approach does not work well 

for other applications, for example metal-removing applications. There are several reasons 
for this. First, there can be considerable variation in how components, such as sensors and 
actuators, combine to produce even simple mechanisms. Second, processes like metal 
removing normally require tightly controlled interaction between many individual 
mechanisms. Exchanging signals called interlocks between the control logic modules of the 
individual mechanisms control the interaction. The application of specific interlocks depends 
on knowledge of the process and the overall control strategy, information not generally 
needed or knowable when the control logic for each mechanism is defined. 
[0031] For example, a drill is a typical metal-removing tool used in the automotive 

industry. In this example an ideal drill is mounted on a carriage that rides along a rail 
between two separate limiting positions on a linear axis, an advanced position and a returned 
position. Two limit switches, referred to herein as returned and advanced LSs, are positioned 
below the carriage and, when tripped, signal that the drill is in the returned and advanced 
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positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a 
returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the 
advanced and returned positions are reached, respectively. In the ideal case, both LSs may be 
assumed to be wired in the same "normally opened" manner, so that electrically speaking 
they are open when released and closed when triggered. In this ideal case, where the physical 
characteristics of the switches are limited, a single LL logic rung can determine when the drill 
is in the returned position and another rung can determine when the drill is in the advanced 
position. 

[0032] Unfortunately, in reality, there are electrically two types of LSs, one LS type 

being wired normally opened and the other type wired normally closed. Furthermore, any LS 
can be mechanically installed in a tripped- when-activated configuration, or a released- when- 
activated configuration. All combinations of these types are used for various types of 
applications. Thus, application requirements may demand control logic capable of handling 
any configuration of LS types. 

[0033] Simple mathematics demonstrates that with two different electrical types of 

LSs and two mechanical configurations, there are sixteen possible configurations of a two- 
position linear slide. Consider the language modules required to implement position logic for 
all these configurations. To accommodate all sixteen-switch configurations, there could be 
sixteen different language modules, each containing fixed LL logic, and each named for the 
case it could handle. In this case, there would be duplicate logic under different names. 
Alternatively, four unique language modules could be provided, but then the user would have 
difficulty identifying which of the sixteen physical configurations that the four modules could 
handle. 

[0034] Clearly, even for a simple drill mounted on a two position linear slide, 

application variables make it difficult to provide a workable library of fixed language 
modules. Adding more switches to the linear slide only increases, to an unmanageable level, 
the number of language modules required in the library. 

[0035] Moreover, the contents of a complete language module for a drill must also 

consider other variables. These variables include, for example, the number and type of 
actuators required; the type of spindle, if any; whether or not a bushing plate is required; what 
type of conveyor is used; whether or not the drill will include an operator panel to enable 
local control. If an operator panel is included, what type of controls (i.e. buttons, switches 
and indicator lights) are required, just to name a few. Each tool variable increases the 
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required number of unique LL modules by more than a factor of two, which makes it difficult 

at best to provide an LL library module for each possible drill configuration. 

[0036] Taking into account the large number of different yet possible machine-line 

tools, each tool having its own set of variables, the task of providing an all-encompassing 

library of fixed language modules becomes impractical Even if such a library could be 

fashioned, the task of choosing the correct module to control a given tool would probably be 

more difficult than programming the required LL logic from scratch. 

[0037] For these reasons, although attempts have been made at providing 

comprehensive libraries of fixed language modules, none has proven particularly successful 

and much LL programming is done from scratch. 

[0038] Third, the process of generating schematic control diagrams is extremely labor 

intensive and thus time consuming. This is because most schematic control diagrams have to 
be constructed by hand linking electrical and hydraulic lines from one control mechanism to 
another, from devices to a PLC representation, linking control devices to mechanical tools 
and so on. 

[0039] To reduce the time required to generate control system schematics, most 

control engineers now use one or more commercially available CAD systems specifically 
designed for generating schematic designs. These CAD systems enable an engineer to select 
standard representations for specific control mechanisms and enable relatively quick 
electrical and hydraulic linking representations to be generated. Nevertheless, these CAD 
systems can result in erroneous connection specification as a control engineer makes the 
decisions about how to link control mechanisms. This is particularly true in the case of a 
large control system where only a small portion of the entire control system can be viewed on 
a work station screen at one time. In this case, the possibility of linking electrical and 
hydraulic lines incorrectly is exacerbated. Moreover, in complex control systems, while 
reducing the overall time required to form a control system schematic, the time is still 
appreciable. 

[0040] Fourth, the process of generating diagnostic tools is also not streamlined. For 

example, there may be specific conditions which should not occur during a machining cycle. 
For instance, where the control mechanisms for a clamp include both extended and retracted 
limit switches, there should never be an instance when both the extended and retracted 
switches are triggered. Unlikely or unpredictable conditions are referred to hereinafter as 
interesting conditions. In current systems, a control engineer should identify the most 
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troubling interesting conditions which should be identified during a machining cycle and 
provide logic outputs to support indicators of the interesting conditions. 
[0041] In addition, some systems require actual diagnostic functions to be performed. 

For example, many times an interesting condition has only one or two possible causes. In 
these cases, the system may be required to, when the interesting condition occurs, identify the 
possible causes so that a system operator can locate the cause of the interesting condition and 
eliminate the cause. Here, the system usually includes a screen for providing an 
alphanumeric message to the operator. 

[0042] Moreover, some applications may require a system to attempt to further 

identify or even eliminate the cause of an interesting condition. In this case, when an 
interesting condition occurs, the system may check other system I/O to further diagnose the 
cause of the condition, providing a report to the operator via a system screen. In the 
alternative, when an interesting condition occurs and there is only one possible cause, the 
system may attempt to eliminate the condition. For example, where a transfer bar is stuck, 
the system may be programmed to reverse the transfer bar prior to moving forward again. 
[0043] Where a system requires diagnostic functions in addition to interesting 

condition reporting, in addition to identifying interesting conditions, the control engineer has 
to identify all possible causes of each interesting condition, compose informative instructions 
for display to an operator indicating the causes of the interesting conditions, provide logic to 
identify the interesting conditions and, in some cases, provide logic to eliminate the 
interesting conditions. 

[0044] In addition to interesting conditions which should not occur, there may also be 

other interesting conditions which should be reported to a system operator. In these cases 
diagnostic logic should be provided to identify these other interesting conditions and provide 
some type of indication. Clearly identifying all interesting conditions and their causes, 
composing messages for each cause and providing logic to do the same is a complex and time 
consuming endeavor. 

[0045] Fifth, the process of specifying HMI design and logic required to support HMI 

representations is not streamlined. Here the control engineer, while creating the control logic 
generally, has to weave HMI logic into the system which provides desired PLC input signals 
(e.g. signals from sensors) and enables control via PLC output signals to control actuators. 
[0046] Sixth, the process of debugging is not streamlined. As indicated above, an 

entire mechanical line (including all tools and accompanying control system) has to actually 
be designed and constructed and PLC execution code has to be generated prior to performing 
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the debugging process. Obviously, once tools have been constructed and execution code has 
been provided the process of backtracking to modify design is difficult and extremely costly. 
[0047] Seventh, while the process described above may be manageable for a single 

door frame assembly, similar processes are required for virtually every separate part of a final 
product and similar processes are also required to assemble parts into the final product. For 
example, because a typical automobile requires many thousands of different parts, a 
development process similar to the process described above must be repeated several 
thousand times to provide a completed automobile. 

[0048] In the end, if line throughput is not sufficient parts of the line or even the 

entire line may have to be modified to increase line throughput. Once again, line 
modification is expensive as any system change can ripple through the entire control system 
thereby requiring additional changes. 

[0049] To streamline the debugging process and facilitate cost justification prior to 

actually building and testing a manufacturing line, the industry has attempted to debug an 
automated manufacturing line virtually. In theory, virtual building and simulation enables a 
designer to modify line design relatively inexpensively when a bug is identified or when the 
costs associated with a particular line design cannot be justified by an expected throughput. 
[0050] One virtual simulation solution has been to effectively provide a cartoon or 

movie illustrating all mechanical tools on a line in three dimensions and to run the 
manufacturing line in the virtual world to illustrate system operation. One way to accomplish 
this is to provide a video module which includes a video clip for each separate mechanical 
tool included on an assembly line. The video module is driven by the mechanical timing 
diagram such that, when the timing diagram indicates a specific resource movement, the 
video module plays the video clip associated with the specific resource movement. The 
video module is capable of running several video clips at a time on different sections of a 
display screen so that, by arranging the separate video clips on the screen a general picture of 
a complete manufacturing process can be provided. While this solution is helpful in 
visualizing a manufacturing process, unfortunately this solution does not illustrate tool 
control in the real world which will result from actual execution code. 

[0051] Another virtual simulation solution has been to provide off-line programming 

for certain tools which is then linked to virtual representations of those tools for simulating 
actual tool movements. For example, most robots are controlled by specialized controllers 
which execute controller specific languages (i.e. languages which typically are very different 
than the PLC language) in such a way that a robot can move a work piece through space 
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along a variety of path profiles. Some companies have developed virtual simulation tools 
which enable robot programs which are developed off-line and in the controller specific 
languages to be used to drive virtual representations of the robot and a work piece handled 
thereby, including robot and work piece translation through virtual space. Importantly, the 
actual program used to drive the robot in the real world is used to drive the virtual robot in 
the virtual environment. As described above, the components in the work cell (including the 
part or part components) already exist in some mechanical CAD environment and are 
available to these programming tools. With these simulation tools a process engineer can 
interact with a virtual work cell and verify that his robot program does what he intends the 
program to do. 

[0052] In order to truly debug the robot program in a virtual world, the rest of the 

robot's real world environment must also be simulated such that the environment interacts 
dynamically with the robot motion. For example, clamps need to open and close, parts need 
to move into and out of the work cell, humans need to start and stop processes, sensors need 
to sense part and manufacturing tool locations and so on. 

[0053] Unfortunately, while the simulation tools described above are used to drive 

virtual robots with the actual robot programs which will be used in the real world, similar 
tools have not been developed for simulating the robot environment (e.g. clamps, sensors, 
actuators, stops and starts, contingencies, HMIs, etc.). Existing tools simulate the robot's 
environment in the virtual world through a combination of proprietary modeling languages 
and graphical interfaces which are wholly disconnected from the programs which are used to 
control the manufacturing tools in the real world. Thus, while the virtual environment is 
controlled via modeling languages, in the real world these non-robotic components are 
controlled via a PLC and a control language (e.g. LL). 

[0054] It should also be noted that, while robots themselves are internally controlled 

via controller specific languages, ultimately, each robot is linked to other system tools via a 
PLC which provides commands and receives feedback via a more conventional control 
language. 

[0055] To provide pre-construction cost justification, in addition to the virtual 

simulation tools described above, various systems have been developed for estimating both 
the costs associated with automated manufacturing lines and groups of related lines and the 
throughput for specific lines. While these justification system may sometimes fortuitously 
generate cost data which is close to the actual cost data corresponding to a completed system, 
in most cases these justification systems provide a ball park figure at best. Unfortunately, 
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while a ball park figure may be acceptable in some industries, in other industries where 
competition is particularly keen, such ball park figures are not very helpful in strategic 
financial planning as even a few percent error may require line redesign. 
[0056] Thus, it should be appreciated that despite industry efforts to streamline the 

development process, the development process remains extremely complex. The transition 
from part design to process design to mechanical design and then to controls is a paper 
activity. Each of these activities separately have their own software tools, and of course, a 
competent set of engineers. The barriers between the software tools aren't just a matter of 
bridging different data types. Because the tools used in each phase of the development 
process evolved through solving their respective user's unique problems, their views of the 
world are very different, even though they ultimately solve a common problem: how to build 
a product. 

[0057] In addition to the system development problems discussed above, failure and 

interesting condition reporting diagnostics have a number of shortcomings. One important 
shortcoming is that a system which supports interesting condition or failure reporting 
typically provides insufficient information to enable a system operator to identify the cause of 
the failure. This is because system events may be contingent upon the conclusion of many 
other events and the diagnostics provided typically cannot indicate which of a long string of 
contingent events causes a failure or an interesting condition to occur. For example, where 
extension of a clamp is to be monitored and failure reported, if clamp extension is contingent 
upon 10 previous events, when clamp failure occurs and is reported, which of the 10 previous 
events failed is not reported and some investigation is required. 

[0058] In addition, where prescriptive diagnostics are provided, the prescriptive 

messages (i.e., the text which indicates likely cause of the problem) are only pre-failure 
hunches as to what the actual cause of failure might be. While based on experience and hence 
correct much of the time, these hunches may not be correct and hence may lead an operator in 
the wrong direction to address the failure this wasting system and operator resources. 
[0059] For example, while the process engineer can specify specific tools and 

movements required to carry out a process, the process information is in a form which, while 
providing specifying information to the control engineer, cannot be used directly by control 
engineers to perform his development tasks. Instead, each time the development process is 
handed from one engineer to another, the receiving engineer must start by generating his own 
set of information which is based on the information specified by the previous engineers and, 
only then can the receiving engineer begin to perform his task of specifying further 
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information for the next engineer down stream. Thus, the development process is broken up 
into separate pieces despite the fact that common information threads pass through each of 
the separate phases of the development process. 

[0060] For at least the aforementioned reasons, it would be advantageous to have a 

system which would streamline the entire development process including defining an 
automated manufacturing line, developing execution code to control the manufacturing line 
tools including tool movements, sequencing, emergency situations, etc., specifying and 
supporting HMIs for the line, specifying diagnostics for the line, simulating line operation in 
a virtual environment prior to building the line and using the actual real world control 
programs to drive a virtual line in the virtual environment, debugging the control programs, 
and providing schematic diagrams for a complete control system automatically. It would also 
be advantageous to have a system wherein the common threads of information which are 
provided by one engineer are sustained throughout the development process and 
automatically provided in a form which is useable by engineers in subsequent process phases. 
[0061] Moreover, it would be advantageous to have a diagnostics scheme which 

could specifically and immediately identify the symptoms which are associated with a failure. 

BRIEF SUMMARY OF THE INVENTION 

[0062] It has been recognized that during the development process there are certain 

common information threads which pass through various development process phases. By 
studying the information passed from one process phase to the next, inventive tools have 
been developed which enable one engineer to use information in the form provided by 
previous engineers to continue the development process without reworking the received 
information. In this manner, the common threads of information flow continuously through 
the development process from beginning to end. 

[0063] It has further been recognized that the control engineering phase is a critical 

juncture for the common threads of information and, that by providing suitable tools to the 
control engineer which organize the development information, the entire development 
process can be streamlined and many advantages result. In effect, the inventive tools operate 
as a lynchpin which enables a control engineer to easily generate controls information from 
the process information (i.e. specified mechanical tools, behavior and sequencing) and which 
also enables controls information to be fed back and combined with the process information 
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to virtually simulate a manufacturing process using the actual execution code which will be 
used in the real world. 

[0064] To this end, among other things, the present invention includes a data 

construct referred to generally as a "control assembly" (CA). It is contemplated that a 
plurality of different CAS will be provided, a separate CA for each type of mechanical 
resource which may be specified by a process engineer. Each CA includes several different 
information types associated with the specific CA. For example, a CA for controlling a 
specific clamp may include: (1) specification of control mechanisms for controlling the 
clamp; (2) a schematic diagram of the clamp illustrating clamp control mechanisms and 
electrical and hydraulic links; (3) logic for controlling the control mechanisms used to in turn 
control the specific clamp; (4) diagnostic logic for indicating either erroneous conditions 
which occur, other interesting conditions or status of a process, (5) logic for supporting an 
HMI associated with the clamp; and (6) simulation specification for simulation purposes. 
Herein, the term "logic" is used to refer to sequencing rules associated with the control 
mechanisms corresponding to a specific CA. 

[0065] As another example, a CA for controlling a robot may include: (1) 

specification mapping PLC I/O to robot I/O; (2) a schematic diagram referencing the inputs 
and outputs and electrical and hydraulic links; (3) logic for interfacing to the robot; (4) 
diagnostic logic for indicating interesting conditions; (5) logic for supporting an HMI 
associated with the robot; and (6) simulation specification for simulation purposes. The CA 
is essentially an object in an object oriented system for specifying information which a 
control engineer must generate for an associated mechanical resource. 
[0066] By observing the process information, including specified mechanical 

resources, mechanical resource behavior and mechanical resource sequencing, an engineer 
can divide the mechanical resources into separate mechanical blocks, each block assigned to 
a specific instance of a C A. By including each mechanical resource in a mechanical block 
and assigning a CA for each mechanical block, control information is easily specified for 
each mechanical resource. 

[0067] After all CAS have been specified, an inventive compiler is used to compile 

all of the information in the CAS and to generate several different types of information. To 
this end, the compiler compiles the schematic diagrams of the separate control devices, 
linking the devices according to a schematic rule set (SRS) to generate a complete schematic 
illustrating all line control devices, controllers and electrical and hydraulic links 
therebetween. 
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[0068] In addition, the compiler uses the logic from each of the CAS to generate 

execution code for controlling and monitoring the entire manufacturing line. 
[0069] Moreover, the compiler compiles the HMI logic from each of the CAS into 

HMI supporting code which enables a suitable HMI. 

[0070] Furthermore, the compiler automatically compiles diagnostic information from 

each of the CAS and generates diagnostic code which is interweaved with the control code 
and which can be used to facilitate diagnostic functions during virtual testing and in real 
world operation. 

[0071] In addition to the CA structure and the inventive compiler, the invention 

further include a CA editor which enable a control engineer to easily link to process 
information upstream thereby streamlining the processes of generating the controls 
information by carrying common threads of information from the process information into 
the controls information. To this end, mechanical resources, their behavior and their 
sequencing is displayed on a CA editor screen as a mechanical timing diagram with 
mechanical resources and specific behaviors along a vertical axis and behavior sequencing 
mapped along a horizontal timing axis. 

[0072] Using the CA editor, the control engineer identifies specific mechanical 

resource types on the mechanical timing diagram and selects suitable CAS for controlling 
each of the mechanical resources or blocks of mechanical resources which can be controlled 
by a single CA. As a CA is selected, the CA editor automatically creates an instance of the 
CA and places the CA in a control bar chart. The control bar chart includes CAS and CA 
behavior along the vertical axis and sequencing of CA behavior along a horizontal time axis. 
To distinguish between CA behavior and mechanical resource behavior, CA behavior will be 
referred to hereinafter as CA requests. 

[0073] In one embodiment, as CA requests are added to the timing diagram, the 

requests are sequenced in the same timing sequence as associated mechanical resource 
behavior in the timing diagram. For example, if the first mechanical resource behavior in a 
process is to close a clamp within a first period, the CA request to extend a piston (i.e. an 
actuator) to close the clamp is placed in the bar chart during the first period. If the clamp 
behavior in the timing diagram is to open during a tenth period, the CA request to retract the 
piston to open the clamp is placed in the bar chart during the tenth period and so on. 
[0074] After all CAS have been selected and the control bar chart is completely 

populated, the CA editor enables the control engineer to specify contingencies at the edges of 
each request in the bar chart. In addition to the CA editor, the invention is meant to be used 
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with an HMI editor and a diagnostics editor, each of which use CA information to configure 
and specify HMI and diagnostics features, respectively. After all of the sequencing 
information required to completely control the control system has been provided, an 
inventive compiler is used to generate execution code as described above. 
[0075] Moreover, the CA simulation specification can be used to provide at least a 

subset of data which is required by a simulator for virtually simulating a process via video 
screens or the like. To this end, a core modeling system (CMS) is a simulator which models 
all aspects of mechanical resources supported by a system and which are simulatable. For 
example, when suitably programmed a CMS may model several different mechanical 
resources including a clamp with position sensors. Clamp operation may have specific 
characteristics such as reversibility, average stroke speed, velocity limiting factors, a variable 
stroke speed curve between start and stop, operating characteristics which change as a 
function of environmental characteristics (e.g. temperature, humidity, etc.) and so on. To 
model mechanical resources a CMS requires a plurality of data structures, a separate data 
structure for each simulatable resource in each instantiated CA. Unlike a one-to-one I/O- 
function paring, advanced data structures reflect real world resource behavior wherein request 
execution varies as a function of a plurality of different circumstantial characteristics. 
[0076] A CMS which is equipped with separate data structures for each simulatable 

resource in each instantiated CA can operate as an interface between a PLC and a movie 
module to receive PLC I/O combinations and, based thereon, cause the movie module to 
virtually simulate the mechanical resources. The CMS also provides feedback to the PLC. 
Behavior characteristics such as simulation speed are simulated by the CMS controlling 
movie frame speed. 

[0077] To facilitate data structure specification, the present invention contemplates 

that information required to form the structures portion thereof may be specified in CA 
simulation specifications and could be imported by the CMS for simulation purposes. While 
any sub-set of simulation information required by a CMS may be specified in a CA 
simulation specification, there is a specific information sub-set which is particularly easy to 
support and which makes sense to specify within a CA. To this end, the characteristics of a 
mechanical resource set associated with a specific CA which affect resource operation can be 
divided into two general categories or first and second simulation information sets including 
control characteristics and circumstantial characteristics. 

[0078] On one hand, with respect to control characteristics, from a controls 

perspective, a sub-set of resource characteristics are fundamental to the specific resource and 
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do not vary as a function of the circumstances related to the resource (i.e., are universal for 
the specific resource). For example, many hardware vendor's provide clamps including 
control mechanisms (e.g., valves, cylindicators, etc.) which, although configured using 
different hardware, perform the same general functions in response to PLC I/O combinations. 
Thus, each clamp will attempt to extend when a PLC "extend" I/O combination is received 
and each clamp will attempt to retract when a PLC "retract" I/O combination is received and 
so on. In this case corresponding I/O-function is independent of hardware configuration. 
Similarly, in this case, the I/O-function pairings are independent of clamp environment 
including temperature, humidity, etc. (i.e., despite temperature and humidity, extension is 
attempted when a specific I/O combination is received). Thus, with respect to similar clamps 
provided by different vendors, I/O-function pairings are control characteristics which are 
universal for clamps which would be used to perform the functions required by a specific 
resource. 

[0079] On the other hand, circumstantial characteristics include all secondary 

characteristics which are not control characteristics and which affect request execution. For 
example, a first manufacturers clamp may have a different closing speed than a second 
manufacturers clamp. Similarly, a first manufacturers clamp may close at different speeds 
depending upon temperature and humidity conditions or speed may vary as a function of 
recent clamp use (e.g., recent closing and opening may result in more rapid closure speed). 
[0080] In a preferred embodiment the CA simulation specifications include only 

control characteristics and do not include circumstantial characteristics. The CMS preferably 
includes a database wherein circumstantial characteristics are stored which can be used to 
alter simulation events making simulation more realistic. The circumstantial characteristics 
are stored in simulation data structure templates (DSTs) and, upon export of the CA 
simulation specification, the control characteristics and circumstantial characteristics are 
combined to populate data structure fields required for simulation. Thereafter the CMS 
receives controller output signals and based on those output signals, modeling algorithms 
within the data structure and other data structure information, causes realistic simulation. 
[0081] In this manner the CA simulation specification is made relatively general and 

the CMS facilitates modification of circumstantial characteristics without recompiling CAS. 
After a data structure is populated, circumstantial characteristics may be modified using a 
CMS interface to reflect various environmental or resource characteristics and simulation will 
also reflect such changes to facilitate realistic simulation. 
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[0082] In addition to facilitating circumstantial characteristic modifications, by 

including only control characteristics in the CA simulation specifications the number of CAS 
required to support design choices is minimized. In effect circumstantial parameterization is 
accomplished via the CMS instead of via the CA. 

[0083] Moreover, dividing characteristics between control and circumstantial 

characteristics and including control characteristics in the CAS makes sense as the control 
characteristics can typically be gleaned from other CA information which is specified for 
other than simulation purposes. For example, where a CA may support anywhere between 
one and four clamps and a user specifies that a CA will support only two clamps such that a 
compiler will provide execution code for controlling two clamps, clearly this 
parameterization will be reflected in simulation such that, during simulation, only two clamp 
animations are generated. Thus, supported CA devices are specified for control purposes and 
such specification is also useful for simulation purposes. In effect, the effort required to 
specify two clamps for execution code purposes can be exploited a second time for 
generating control characteristics required for simulation. While this example is relatively 
simple, it should be appreciated that a huge amount of specification required for execution 
code purposes is exploited in this double-duty fashion thereby appreciably streamlining an 
otherwise daunting simulation specification process. 

[0084] In another embodiment, the data required to populate essentially an entire data 

structure including both control and circumstantial characteristics may be specified within 
each CA simulation specification. In this case, upon compiling, sub-sets of the required 
simulation information for each simulatable resource are gleaned from each parameterized 
CA and are used to populate the data structures. After compiling, the data structure are 
imported by the CMS and then used for interfacing purposes. Other simulation specification 
embodiments may include other sub-sets of control and circumstantial characteristics. 
[0085] In a simplified embodiment of the invention where a one-to-one pairing of 

PLC I/O and virtual simulation is supported without circumstantial characteristics, the 
parameterization simulation specification may simply be a PLC I/O mapping table which 
maps PLC I/O combinations to specific video clips. In this case, after the parameterized 
specification is compiled, the specification is imported by the CMS and used for interfacing 
purposes. 

[0086] The inventive address mapper facilitates mapping of PLC I/O to virtual 

mechanical resources to cause virtual simulation, identifies mechanical resource conditions 
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(e.g. position, temperature, etc.) which are to be sensed during real world operation and 
provides inputs to the PLC indicating identified conditions during virtual processing. 
[0087] In addition to control and circumstantial characteristics, a third type of 

character referred to as a third entity characteristic is contemplated. Third entity 
characteristics include characteristics of entities other than mechanical resources which 
interact with the PLC or which only minimally interact with the PLC and which must be 
modeled to facilitate realistic simulation. For example, third entities include system 
operators, a shot pin used to lock two devices together, an E-stop and corresponding 
hardware and so on. 

[0088] Thus, the invention provides a system which streamlines the entire 

development process including defining an automated manufacturing line, developing 
programs to control the manufacturing mechanical resources including resource movements, 
sequencing, emergency situations, etc., specifying and supporting HMIs for the line, 
simulating line operation in a virtual environment prior to building the line and using the 
actual real world execution code to drive a virtual line in the virtual environment, debugging 
the control programs, and automatically providing schematic diagrams for a complete control 
system. 

[0089] In addition to the inventive aspects described above, in another aspect the 

invention includes status based diagnostics wherein every event which is to occur during a 
process is monitored and, when an expected event fails to occur, the failed event is reported. 
For example, where a clamp extension request is contingent upon the occurrence of ten 
previous events, when one of the previous events fails, status based diagnostics reports the 
failed event. In this manner, when a failure occurs, the specific symptoms of the failure are 
immediately reported and the operator can then surmise the cause of the failure quickly. 
[0090] Request events are represented in the CAS and therefore status based 

diagnostics can easily be provided in each CA to minimize the task of programming 
diagnostics code for each event in a process. For example, where a clamp CA includes 
extend and retract requests and ten separate events, diagnostics can be provided once for each 
event in a template CA and, therefore, as CA instances are instantiated (i.e. selected by an 
operator for control purposes), the status based diagnostics are proliferated throughout the 
control process. In this manner, the task of providing status based diagnostics which seemed 
virtually impossible before can easily be accomplished through CA duplication (i.e., 
instantiation). 
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[0091] These and other objects, advantages and aspects of the invention will become 

apparent from the following description. In the description, reference is made to the 
accompanying drawings which form a part hereof, and in which there is shown a preferred 
embodiment of the invention. Such embodiment does not necessarily represent the full scope 
of the invention and reference is made therefore, to the claims herein for interpreting the 
scope of the invention. 

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 

[0092] Fig. 1 A is a block schematic diagram of a computer system for example, a 

personal computer system in accordance with a preferred embodiment; 

[0093] Fig. IB provides a display of ladder logic in accordance with a preferred 

embodiment; 

[0094] Fig. 2 illustrates an enterprise control system in accordance with a preferred 

embodiment; 

[0095] Fig. 3 illustrates a CA display from an enterprise control database in 

accordance with a preferred embodiment; 

[0096] Fig. 4 is a block diagram depicting the logical flow of the enterprise control 

system in accordance with a preferred embodiment; 

[0097] Fig. 5 A is a block diagram schematic representing a system including a 

diagnostic engine for diagnosing the behavior of a machine controlled by a discrete event 
control system in accordance with a preferred embodiment of the present invention; 
[0098] Fig. 5B is a flow chart representing exemplary steps for defining, updating and 

selecting the optimum diagnostic rules for the system of Fig. 5 a while the diagnostic engine is 
in the learning mode; 

[0099] Fig. 5C is a flow chart representing exemplary steps for identifying a 

malfunction in the behavior of the machine and updating the timing statistics associated with 
the diagnostic rules while the diagnostic engine of Fig. 5a is in the diagnostic mode; 
[00100] Fig. 6 illustrates the user display for opening a project in accordance with a 

preferred embodiment; 

[00101] Fig. 7 is a Designer Studio window in accordance with a preferred 

embodiment; 

[00102] Fig. 8 is a Designer Studio display with CAS completed in accordance with a 

preferred embodiment; 
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[00103] Fig. 9 is a CA wizard in accordance with a preferred embodiment; 

[00104] Fig. 10 is a CA wizard name operation in accordance with a preferred 

embodiment; 

[00105] Fig. 1 1 is a CA wizard to select control resources in accordance with a 

preferred embodiment; 

[00106] Fig. 12 is a CA wizard to label components associated with the CA in 

accordance with a preferred embodiment; 

[00107] Fig. 13 is a CA wizard summary in accordance with a preferred embodiment; 

[00108] Fig. 14 is a Designer Studio display of a new CA integration in accordance 

with a preferred embodiment; and 

[00109] Fig. 15 is a schematic of a pneumatic system of a control environment in 

accordance with a preferred embodiment; 

[001 10] Fig. 16 illustrates the hierarchical relationship between a machine and an 

indexer in accordance with a preferred embodiment; 

[001 1 1] Fig. 17 illustrates a template in accordance with a preferred embodiment; 

[001 12] Fig. 18 illustrates a machine tree in accordance with a preferred embodiment; 

Fig. 19 illustrates a master control panel in accordance with a preferred embodiment; 
[001 13] Fig. 20 illustrates the symbolic expression language in accordance with a 

preferred embodiment; 

[001 14] Fig. 21 illustrates an exemplary rung in accordance with a preferred 

embodiment; 

[001 15] Fig. 22 illustrates a required full set of conditions in accordance with a 

preferred embodiment; 

[001 16] Figs. 23-35 illustrate an exemplary set of templates in accordance with a 

preferred embodiment; 

[001 17] Fig. 36 is a flow chart of the process by which the user creates the control 

diagram in accordance with a preferred embodiment; 

[001 18] Figs. 37-43, represent all of the templates required to completely specify an 

axis in accordance with a preferred embodiment; 

[001 19] Fig. 44 illustrates a control panel editor in accordance with a preferred 

embodiment; 

[00120] Figs. 45 & 46 illustrate bar chart images in accordance with a preferred 

embodiment; 

[00121] Fig. 47 is a contingency screen in accordance with a preferred embodiment; 
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[00122] Fig. 48 is a flowchart detailing the logic associated with compilation in 

accordance with a preferred embodiment; 

[00123] Fig. 49 A and 49B are ladder logic displays in accordance with a preferred 

embodiment; 

[00124] Fig. 50 illustrates an attributes table in accordance with a preferred 

embodiment; 

[00125] Fig. 51 is a ladder logic display in accordance with a preferred embodiment; 

[00126] Fig. 52 is a flowchart of observed functional processing in accordance with a 

preferred embodiment; 

[00127] Fig. 53 is a flowchart of bucket processing in accordance with a preferred 

embodiment; 

[00128] Fig. 54 is a splash screen in accordance with a preferred embodiment; 

[00129] Fig. 55 is the initial display for the Designer Studio in accordance with a 

preferred embodiment; 

[00130] Fig. 56 illustrates a menu that is utilized to open a project in accordance with a 

preferred embodiment; 

[00131] Fig. 57 illustrates a display menu that is utilized to select an existing project to 

load in accordance with a preferred embodiment; 

[00132] Fig. 58 illustrates an Open Project dialog in accordance with a preferred 

embodiment; 

[00133] Fig. 59 illustrates a menu display for facilitating an "Add CA" dialog 5900 in 

accordance with a preferred embodiment; 

[00134] Fig. 60 illustrates the first menu in an "Add CA" dialog in accordance with a 

preferred embodiment; 

[00135] Figs. 61 to 67 illustrate a user experience with a wizard in accordance with a 

preferred embodiment; and 

[00136] Fig. 68 illustrates the processing that occurs when a user presses the finish 

button in accordance with a preferred embodiment; 

[00137] Fig. 69 illustrates the selection processing associated with a particular CA in 

accordance with a preferred embodiment; 

[00138] Fig. 70 illustrates the processing of a CA in accordance with a preferred 

embodiment; 

[00139] Figs. 71 to 79 provide additional displays in accordance with a preferred 

embodiment; 
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[00140] Fig. 80 is a block diagram of a CA in accordance with a preferred 

embodiment; 

[00141] Fig. 81 is a schematic representation of an exemplary control device for 

controlling a cylindicator control mechanism; 

[00142] Fig. 82 is similar to Fig. 81, albeit for a two position valve control mechanism; 

[00143] Fig. 83 is similar to Fig. 81, albeit for a spring return valve control 

mechanism; 

[00144] Fig. 84 is a schematic illustrating the various sections of an exemplary control 

assembly; 

[00145] Fig. 85 is a schematic diagram illustrating an exemplary logic specification of 

Fig. 84; 

[00146] Fig. 86 is a schematic illustrating an exemplary HMI specification of Fig. 84; 

[00147] Fig. 87 is a schematic illustrating an exemplary diagnostics specification of 

Fig. 84; 

[00148] Fig. 87 A is a schematic illustrating an exemplary status based diagnostics 

specifications; 

[00149] Fig. 88 is a schematic illustrating an exemplary simulation specification of 

Fig. 84; 

[00150] Fig. 89 is an exemplary control bar chart used to sequence control assemblies 

according to the present invention; 

[00151] Fig. 90 is a block diagram illustrating various components of a system used to 

practice the present invention; 

[00152] Fig. 91 is an exemplary mechanical resource timing diagram; 

[00153] Fig. 92 is a schematic illustrating an exemplary resource editor window 

according to the present invention; 

[00154] Fig. 93 is similar to Fig. 92, albeit illustrating a second editor window; 

[00155] Fig. 94 is similar to Fig. 92, albeit illustrating yet another editor window; 

[00156] Fig. 95 is a schematic illustrating an exemplary HMI screen; 

[00157] Fig. 96 is a schematic similar to Fig. 92, albeit illustrating yet another editor 

window; 

[00158] Fig. 97 is a schematic diagram illustrating an HMI editor screen according to 

the present invention; 

[00159] Fig. 98 is a schematic illustrating an HMI editor screen for selecting 

monitorable and controllable I/O; 
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[00160] Fig. 99 is a schematic illustrating a diagnostics editor screen; 

[00161] Fig. 100 is a schematic diagram illustrating a diagnostics editor screen for 

selecting diagnostics to be supported by a control system; 

[00162] Fig. 101 is a schematic diagram of the PLC of Fig. 90; 

[00163] Fig. 102 is a schematic diagram illustrating an exemplary PLC I/O table; 

[00164] Fig. 103 is a schematic diagram illustrating an exemplary HMI linking table; 

[00165] Fig. 104 is a schematic diagram illustrating an exemplary diagnostics linking 

table; 

[00166] Fig. 105 is a schematic diagram illustrating the compiler of Fig. 90; 

[00167] Fig. 106 is a schematic diagram illustrating an exemplary code building table; 

[00168] Fig. 107 is a schematic diagram illustrating the exemplary PLC I/O table 

segment of Fig. 106; 

[00169] Fig. 108 is a schematic diagram similar to Fig. 107 albeit illustrating a 

different table segment; 

[00170] Fig. 109 is a block diagram illustrating an exemplary code and PLC I/O 

compilation method according to the present invention; 
[00171] Fig. 1 10 is an exemplary HMI building table; 

[00172] Fig. Ill is a schematic diagram of a exemplary diagnostics building table; 

[00173] Fig. 1 12 is a block diagram of an exemplary method for compiling and HMI 

linking table and a diagnostics linking table; 

[00174] Fig. 1 13 is a schematic diagram of an exemplary schematic building table; 

[001 75] Fig. 1 14 is a block diagram of an inventive method for compiling a schematic 

diagram according to the present invention; 

[00176] Fig. 1 15 is a schematic diagram of an exemplary simulation building table; 

[00177] Fig. 1 16 is a block diagram of a inventive simulation table compiling process; 

[00178] Fig. 1 17 is a schematic diagram of the core modeling system of Fig. 90; 

[00179] Fig. 1 18 is a schematic diagram of one of the data structures of Fig. 117; 

[00180] Fig. 1 19 is a flow chart illustrating an inventive method for combining control 

characteristics from simulation specifications and circumstantial characteristics to provide 
instantiated data structure instances; 

[00181] Fig. 120 is a flow chart illustrating an exemplary simulation method using the 

data structures of Fig. 117; and 

[00182] Fig. 121 is a schematic diagram of a third entity data structure according to the 

present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 



[00183] Newly Added Specification 

While it is contemplated that the inventive editors and database may be implemented 
in any of several different computer technologies, preferably, the editors are implemented 
using universal technologies such as JAVA by Sun Microsystems or ActiveX by Microsoft. 
Also, while it is contemplated that the PLC logic may be implemented in any of several 
different computer languages, because most PLCs run relay ladder logic (LL) programs, it is 
preferred that the PLC logic be in the LL language and is described as such hereinafter. 
[00184] Unless indicated otherwise, identical numbers and legends on different Figures 

are used to refer to identical system components, signals, constructs and so on. 
[00185] While the invention includes various interfaces and editors for enabling a 

system user to specify logic, initially an industrial controls paradigm will be explained which 
serves as a foundation for the inventive editors, compiler and simulator. This paradigm will 
make all of the aspects of the present invention more easily understandable. After the 
industrial controls paradigm is described, a CA editor, an HMI editor and a diagnostics editor 
are described which use the controls paradigm to specify controls logic. Next, the inventive 
compiler is described followed by the inventive simulator which uses compiler output to 
drive a virtual machine line using real world execution code. 
[00186] A. Industrial Control Paradigm 

When performing the controls engineering tasks, a control engineer has to provide 
many different types of controls information including, among other types: (1) control 
mechanism specification; (2) logic or execution code to control the control mechanisms; (3) 
logic or execution code to support diagnostic requirements; (4) logic or execution code to 
support HMIs; (5) schematic electrical and hydraulic diagrams and so on. Hereinafter, all of 
the controls information provided at the end of a control engineering process will be referred 
to generally as "control products." 

[00187] It has been recognized that system control can be divided into a hierarchy of 

separate control levels, each level including similar control concepts and each higher level 
including instances of control concepts from the immediately lower level. It has also been 
recognized that each of the separate control levels lends itself uniquely to specifying one or 
more types or sub-types of the control information which must be specified during the control 
engineering process. 
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[00188] The hierarchy consists primarily of four separate control levels which can be 

used together to specify, virtually construct, simulate and debug a control system for any 
mechanical process including any type of mechanical resource. The four levels include what 
will be referred to hereinafter as factory floor input and output signals (i.e. the I/O level), 
control devices, control assemblies and control sequencing. 
[00189] 1. Factory Floor I/O 

As a general rule, a mechanical resource itself is simply a tool which, although 
capable of certain movements, cannot cause a movement to occur. To cause mechanical 
resource movement, one or more control mechanisms have to be linked to the mechanical 
resource. For example, in the case of a clamp which includes a clamping surface (i.e. the 
surface which moves toward an opposite surface to close), the control mechanisms may 
include a cylinder and a two position valve wherein a cylinder piston is linked to the clamp 
surface and the valve includes both extend and retract solenoids which can be controlled to 
extend or close the clamp surface or to retract or open the surface, respectively. When the 
extend solenoid is excited, an armature linked thereto allows high pressure air to force the 
piston and clamp surface into the extended position. When the retract solenoid is excited, the 
armature allows air to force the piston and clamp surface into the retracted position. Thus, in 
this case, two control mechanisms, the cylinder and the valve, are required to move the clamp 
between the open and closed positions. 

[00190] Similarly, as a general rule mechanical resources themselves do not generate 

signals which can be used to determine mechanical resource position for monitoring 
purposes. Instead, specific control mechanisms have to be provided to facilitate monitoring. 
To this end, in the case of the clamp above, where it is important to confirm clamp position 
during a process, the cylinder may be equipped with proximity sensors for sensing the 
position of the cylinder piston to ensure that the piston is in the retracted and extended 
positions when required by the process. 

[00191] To control or manage control mechanisms, control output signals are provided 

by a PLC to the control mechanisms and, the PLC receives input signals from the control 
mechanisms indicating current control mechanism and mechanical resource status. For 
example, an exemplary valve solenoid includes a "hot" terminal and a "common" terminal. 
To excite a solenoid, for safety purposes it is customary to require that each of the hot and 
common terminals be excited. Thus, for a two position valve including two solenoids, a PLC 
must provide four output signals, one hot and one common terminal signal for each of the 
two separate solenoids. For a two sensor cylindicator (i.e. a cylinder with proximity sensors 
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for the piston inside), no PLC outputs are required but the cylindicator provides two input 
signals, one indicating an extended piston and the other indicating a retracted piston. 
[00192] Thus, from the perspective of a control engineer, each of the control 

mechanisms has the appearance of a proverbial "black box" having specific inputs (i.e. 
feedback inputs to the PLC) and outputs (Control Signals from the PLC). Control 
mechanism I/O constitute the factory floor inputs and outputs which make up the lowest or 
I/O controls level. 

[00193] 2. The Control Device (Signal Container) 

In addition to input and output signals, other control information can be specified for 
each of the control mechanisms. For instance, given a specific structure, each control 
mechanism also has specific "normal" or expected states and specific "failure" or unexpected 
states. For example, for the cylindicator described above, a failure state occurs when both the 
extended and retracted proximity sensors generate signals (i.e. indicate piston proximity). All 
other combinations of cylindicator inputs are normal (i.e. both sensors indicating negative or 
one sensor negative while the other is positive). 

[00194] Moreover, for each failure state the control information may include a 

specified activity (e.g. reporting the failure state). For example, where two cylindicator 
sensors simultaneously indicate proximity of the piston, the activity may include generating a 
text message for indicating mechanism failure such as "Cylindicator Sensor Failure". 
[00195] Furthermore, given a specific structure, each control mechanism can be 

represented by a standard schematic symbol preferably similar to the symbols used in the 
industry to represent the specific control mechanism and including connection points for 
different energy transferring media (e.g. electrical, pneumatic and hydraulic inputs and 
outputs, water, mechanical linkages, etc.). In this regard part information relating to the 
specific control mechanism may be included with the schematic symbol. 
[00196] According to the present invention, all of the control information associated 

with each control mechanism is encapsulated in a single data construct referred to herein as a 
"control device" (CD). An exemplary control device includes a device name, a logic section, 
a schematic section and a diagnostics section. While the exemplary CD's include each of 
logic, schematic and diagnostics sections, other less complete CD's are contemplated. For 
example, a CD may not include a schematic section, a diagnostics section or a logic section. 
[00197] Three separate examples of control devices are provided hereinafter to 

illustrate some of the concepts described above. The three examples include a cylindicator 
( see Fig. 81), a two-position valve (see Fig. 82) and a spring return valve ( see Fig. 83). It 
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should be understood that the three exemplary control devices described herein are not meant 
to be exhaustive and that many other control devices are contemplated by the present 
invention. 

[00198] In addition to representing real control mechanisms a control device may also 

represent a "virtual" device such as a robot controller which receives and provides inputs and 
outputs, respectively, from a PLC to enable control and feedback. 
[00199] Thus, control devices have both a logic aspect which defines inputs and 

outputs to and from a controller and a hardware aspect which specifies parts, manufacturers, 
properties and so on. 

[00200] Despite the fact that many control devices include more than just a grouping 

of input and output signals and that other CD's may not include I/O groupings, it is helpful to 
think of an exemplary control device as a signal container including all of the input signals 
provided by a control mechanism to a PLC and all of the output signals provided to the 
control mechanism by the PLC. 
[00201] a. Cvlindicator 

Referring to Fig. 81, a cylindicator control device 8500 includes a device name 8502, 
a logic section 8504, a schematic section 8506 and a diagnostic section 8508. The device 
name 8502 is chosen such that the name will be recognized by an exemplary control engineer 
and will be associated with a corresponding control mechanism. Thus, in the present 
example, the control device 8500 in Fig. 81 is named "cylindicator with two sensors" and 
corresponds to a cylindicator with two proximity sensors as described above. 
[00202] Hereinafter, when describing logic in the context of I/O, I/O generating 

components will be said to be active or excited on one hand or passive on the other hand 
meaning that the components are either providing energized and providing a true signal on 
one hand or passive and providing a negative signal, respectively. In the context of a LL coil, 
an excited coil is associated with a true signal and a coil which is not excited is associated 
with a false signal. In the context of a LL contact, a closed contact is associated with a true 
signal and an open context is associated with a false signal. In addition, in I/O tables, 
condition tables and bar charts which follow, cross hatched boxes indicate active or excited 
I/O and clear boxes indicate passive I/O. 

[00203] Logic section 8504 includes an I/O table 8510, a normal conditions table 8512 

and a failure conditions table 8514. I/O table 8510 indicates sub-mechanisms of each control 
mechanism which are actually linked to specific I/O. Thus, the cylindicator includes both the 
extended proximity sensor 8516 and the retracted proximity sensor 8518 and indicates PLC 



-28- 



inputs 8520, 8522 which are provided by sensors 8516 ad 8518, respectively. In the case of a 
cylindicator there are no outputs (i.e. terminals which receive control signals from a PLC) 
and therefore none are listed. 

[00204] Normal conditions table 8512 indicates all possible normal combinations of 

inputs 8520 and 8522. To this end, table 8512 indicates that when the cylindicator is 
extended, the extend sensor 8516 generates a positive signal indicating piston proximity and 
the retract sensor 8518 is negative, when the cylindicator is retracted, the retract sensor 8518 
generates a positive signal indicating piston proximity and the extend sensor 85 16 is negative 
and when the cylindicator is between the extended and retracted positions, both of the sensors 
8516 and 8518 are negative or passive. 

[00205] The failure table 85 14 indicates all possible failure combinations of inputs 

8520 and 8522. To this end, the only possible failure combination is when each of sensors 

8516 and 8518 generate positive signals indicating piston proximity (i.e. it is impossible for a 

piston to be simultaneously extended and retracted). I 

[00206] Referring still to Fig. 81, schematic section 8506 includes a schematic diagram 

8507 of the control mechanism associated with control device 8500. In this case, the 

schematic 8528 is of a cylindicator with two sensors and includes connector nodes. Although 

not illustrated, other part information may be provided with the schematic (e.g. cost, specific 

mechanical requirements, etc.) 

[00207] The diagnostics section 8508 includes information indicating rules for 

identifying I/O conditions which are "interesting conditions" from a diagnostics perspective 
and indicating activities which should be performed when an interesting condition is 
identified. To this end, section 8508 includes a diagnostics table 8509 including I/O 
requirements 8511 and corresponding activities 8513 wherein each I/O requirement 8511 
identifies a specific set of interesting conditions (i.e. I/O) and the activity 8513 indicates the 
activity to be performed when a corresponding I/O requirement occurs. In the case of a 
cylindicator an interesting condition occurs when both extended and retracted proximity 
sensors 8516 and 8618 generate active input signals indicating the failure condition 8514. In 
table 8509 "failure" 8515 is listed as one requirement or interesting condition. The activity 
associated with failure 8515 is to generate an alphanumeric text phrase "cylindicator sensor 
failure" 8517. 

[00208] Other interesting conditions may include normal condition sets which, for 

some reason (e.g. their order within a sequence), render the normal set diagnostically useful. 
For example, if a particular sequence is not observable in the real world but is important from 
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a diagnostics perspective, it may be advantageous to provide the end condition set of the 
sequence as a requirement in table 8509 and include some type of indicating activity in 
activities column 8513. 

[00209] Other activities, in addition to reporting, may also include diagnostics based 

on prior experience. For example, the text message specified in the activity may indicate the 
likely cause(s) of the interesting condition. Moreover, the text message may also specify a 
prescription to eliminate the diagnosed cause. 

[00210] Furthermore, the diagnostic activity 8513 may also be proactive in diagnosing 

the cause of an interesting condition. To this end, the activity 8513 may specify additional 
I/O to be checked if a specific interesting condition occurs and, based on the additional I/O, 
the activity 8513 may select from a list of other diagnostic activity. 
[0021 1] Moreover, the diagnostic activity 8513 may be proactive in eliminating an 

interesting condition. To this end, the activity 8513 may specify output signals which should 
be modified when a particular interesting condition occurs. For example, in Fig. 81, when a 
failure condition (e.g. 8514) occurs, in addition providing a text phrase, the activity 8513 may 
also modify output signals to clamp valves to open the clamps. 

[00212] In any of these diagnostic cases, the requirements 851 1 include a sub-set of 

specific I/O conditions of the control mechanism and the activities include outputs. The 
diagnostic outputs are, in the case of a text phrase or other indication, to an HMI and, in the 
case of proactive diagnostics or I/O modification, to one or more control mechanisms. 
[00213] b. Two-position Valve 

Referring to Fig. 82, a two-position valve control device 8600 includes a device name 
8602, a logic section 8604, a schematic section 8606 and a diagnostic section 8608. The 
device name 8602 is "two-position valve." 

[00214] The logic section includes an I/O table 8610 and a normal conditions table 

8612. I/O table 8610 indicates sub-mechanisms of each control mechanism which are 
actually linked to specific inputs and outputs. Thus, table 8610 lists both the valve's extend 
solenoid 8616 and retract solenoid 8618 and indicates the PLC outputs provided for each of 
the two solenoids (i.e. outputs 8620 and 8622 to solenoid 8616 and outputs 8621 and 8623 to 
solenoid 8618. In the case of a two position valve there are no inputs (i.e. PLC feedback 
signals) and therefore none are listed. 

[00215] Normal conditions table 8612 indicates all possible normal combinations of 

outputs 8620 through 8623. To this end, table 8612 indicates that when the outputs to 
solenoid 8616 are active, the outputs to solenoid 8618 must be passive and vice versa. 
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[00216] Note that there is no failure conditions table for the two-position valve despite 

the fact that a failure condition could occur. For example, all four outputs 8620 through 8623 
could be active. While a failure table could be provided, providing a failure table is a matter 
of control device designer choice and may depend on the likelihood of a failure occurring, the 
importance of such a failure occurring and which part of a control system likely causes a 
failure. For example, in the case of a valve having no inputs and one or more outputs, any 
failure in outputs would likely be caused by the PLC itself and thus the PLC, not the device 
being controlled thereby, should determine failure. 

[00217] The schematic section 8606 includes a schematic diagram 8628 of a two 

position valve including connector nodes. 

[00218] The diagnostics section 8708 includes diagnostics table 8604 having 

requirement and activity columns 861 1 and 8613, respectively. In this case, because there are 
no failure conditions specified for the two position valve, no failure diagnostics are provided. 
However, the example herein includes diagnostics for another "interesting condition." In this 
case, the interesting condition is when the extend solenoid hot and common outputs are both 
excited and the retract solenoid hot and common outputs are both passive. This condition 
corresponds to an extend request and extend requirement 8615. When the extend 
requirement 8615 is met, the prescribed activity 8617 provides a text message "Extend 
Requested" to an HMI for display. 

[00219] Although a requirement and an activity are listed in table 8609 for exemplary 

purposes, hereinafter, to simplify this explanation, it will be assumed that diagnosis table 
8609 is empty. 

[00220] c. Spring Return Valve 

A spring return valve is a valve which includes a single solenoid, an armature and a 
spring. The solenoid, like other solenoids described above, includes both a hot terminal and a 
common terminal, each of which have to be excited to activate the solenoid. The armature is 
linked to the solenoid and, when the solenoid is activated, the armature is extended against 
the force of the spring. When solenoid power is cut off, the spring forces the armature and 
solenoid back to a steady state position. 

[00221] Referring to Fig. 83, a spring return valve control device 8700 includes a 

device name 8702, a logic section 8704, a schematic section 8706 and a diagnostic section 
8708. The device name 8702 is "spring return valve." 

[00222] The logic section includes an I/O table 8710 and a normal conditions table 

8712. I/O table 8710 indicates sub-mechanisms of the control mechanism which are linked 
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to specific inputs and outputs. Thus, table 8710 lists the valve's extend solenoid 8716 and 
indicates the PLC outputs provided to the extend solenoid (i.e. outputs 8720 and 8722). In 
the case of a spring return valve there are no inputs (i.e. feedback signals to the PLC) and 
therefore none are listed. 

[00223] Normal conditions table 8712 indicates all possible normal combinations of 

outputs 8720 and 8722. To this end, table 8712 indicates that the outputs to solenoid 8716 
have to either be both active or both passive. As with the two-position valve there is no 
failure conditions table for the spring return valve. The schematic section 8706 includes a 
schematic diagram 8728 of a spring return valve including connection nodes. 
[00224] The diagnostics section 8708 includes a diagnostics table 8709 including a 

requirement column and an activity column 871 1, 8713, respectively. In this case, because 
there are no failure conditions specified for the spring return valve, no failure diagnostics are 
provided. Moreover, no other interesting conditions are specified and therefore table 8709 is 
left blank. 

[00225] Thus, a control device is a database construct which includes, but is not 

limited to, all of the control information about a control mechanism which would be specified 
during the control engineering phase of a development process. In addition, as will be 
understood shortly, the control device is a building block from which control assemblies are 
formed. 

[00226] 3. The Control Assembly (Control Device Container) 

Like the control device, a control assembly (CA) according to the present invention is 
a data construct which includes control information. However, while a control device 
includes essentially all of the information which a control engineer specifies with respect to a 
specific control mechanism (e.g. a cylindicator, a valve, etc.), the CA configuration has been 
designed to include essentially all of the information which a control engineer specifies with 
respect to a specific mechanical resource (e.g. a clamp, a robot, etc.) or, in some cases, with 
respect to a group of mechanical resources (e.g. a plurality of clamps which are 
synchronous). To this end an exemplary CA operates proverbially as a "device container" for 
all of the control devices which operate together to control a mechanical resource. 
[00227] The invention contemplates a plurality of different CAS. For example, a 

process engineer may have the choice to select any of three different mechanical clamps for 
clamping a work item in place along a transfer line wherein each of the three clamps requires 
different control mechanisms to control the clamp. 
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[00228] A first clamp type may require only two control mechanisms including one 

two-position control valve and a cylinder. The second clamp type may also require only two 
control devices but the required devices may be different than those required for the first 
clamp type. For example, the second clamp type may require a two position valve and a 
cylinder including two proximity sensors (i.e. a cylindicator). The third clamp type, like the 
second, may require a two-position valve and a cylindicator and, in addition, may also require 
a redundant spring return valve. In this case, the spring return valve is positioned between 
the two position valve and the cylinder. When the spring return solenoid is excited, the 
spring armature extends against the force of the spring and allows high pressure air to force 
the piston and clamp surface into the closed and extended position and, when solenoid power 
is cut off, the spring forces the valve into the retracted position allowing the air to force the 
piston and clamp surface into the open and retracted position. The spring return valve causes 
the clamp to open if power is cut off from the solenoids. 

[00229] In this case, a CA library would include three separate clamp CAS, a separate 

CA for each of the possible clamp types. The information in one CA all corresponds to a 
single mechanical resource and the control devices within the CA which are required to 
control the mechanical resource. For instance, in the clamp example above, the CA 
corresponding to the third clamp type would include only information corresponding to a 
two-position valve, a spring return valve and a cylindicator. 

[00230] In addition to the three CAS described above, the invention contemplates a 

CA library including many more CAS, each CA corresponding to a different set of control 
devices used to control a specific mechanical resource. For example, there may be ten 
different CAS corresponding to ten different robot configurations (i.e. mechanical resources), 
there may be three CAS corresponding to three different pin locator configurations, there may 
be eight CAS corresponding to eight different slide configurations and so on. 
[00231] a. Exemplary CA Structure 

In the interest of simplifying this explanation and an explanation of the control 
paradigm on which the invention rests, an exemplary CA will be described which is 
specifically designed to include control information for the third clamp type above (i.e. a CA 
including a two-position valve, a spring return valve and at least one cylindicator). It will be 
assumed that the exemplary CA can be used to specify control information for anywhere 
between one and four separate clamps for each CA instance. To this end, it has been 
recognized that certain control assemblies and corresponding control mechanisms may be 
capable of controlling more than a single mechanical resource. For example, if air pressure 
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generated by an air source is high enough, air pressure passing through a single valve has 
enough force to simultaneously move two or more clamps. To minimize system costs, a 
single valve design, or any design which reduces the number of control mechanisms, is 
advantageous. While a single valve may be required to move a plurality of clamps, each 
clamp requires a dedicated cylindicator. Thus, the exemplary CA includes control devices 
for controlling up to four cylindicator. 

[00232] In a preferred embodiment a CA is divided into information fields or 

specifications, a separate specification for each one of the different types of control 
information. For example, referring to Fig. 84, an exemplary CA 9000 may include, among 
other information specifications, five control information specifications including (1) logic 
specification 9002; (2) schematics specification 9004; (3) HMI specification 9006; (4) 
diagnostic specification 9008; and (5) simulation specification 9300. 

[00233] In addition, the CA is also provided with a template type indicator 9001. As 

with the control device names, type indicators 9001 are chosen to reflect the nature of the CA 
type so that the content of the CA template can be understood by a control engineer 
essentially from the CA template type identifier 9001. In the present example the type 
indicator 9001 is "SafeBulkHeadClampSet" indicating that the template type is for controlling 
a clamp and defines a redundant spring return valve for safety purposes. 
[00234] In a preferred embodiment of the invention, the CA template includes all 

controls information required for a specific mechanical resource and which can be used over 
and over again to specify the information in separate template instances. When a template is 
accessed for use, the specific template use is referred to as an instance of the CA and the act 
of using the template is referred to as instantiating an instance of the CA. When a CA is 
instantiated, the specific CA instance is given a unique name which is then used thereafter to 
reference the specific CA instance and to identify control system parameters corresponding to 
the instance. For example, where two identical clamp CAS are required to control different 
clamps, the first CA instance may be provided the name "lstclamps" and the second CA 
instance may be provided the name "2nd clamps". Hereinafter, the exemplary CA 9000 
described will be referred to by the name lstclamps 9003. 

[00235] Hereinafter, each of the CA specifications is described separately. Initially, 

each of the exemplary specifications would be generic in the sense that the specification 
would not be parameterized to reflect encapsulated information about a specific CA instance. 
The described specifications, however, reflect CA instance parameterized as will be 
explained in more detail below. 
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[00236] i. Logic Specification 

Referring to Figs. 84 and 85, logic specification 9002 includes I/O tables 
corresponding to each of the control devices which may possibly be included in the CA. 
Thus, for a CA including a two-position valve 9421, a spring return valve 9423 and capable 
of supporting four cylindicators 9425, 9427, 9429 and 9431 (i.e. one cylindicator for each 
controllable clamp), logic specification 9002 includes VO tables 8510a, 8510b, 8510c, 8510d, 
8610 and 8710 ( see also Figs. 81-83). For the purpose of this explanation the two-position 
valve 9421 outputs are referred to as 01, 02, 03 and 04, the spring return valve 9423 outputs 
are referred to as 05 and 06 and the cylindicator inputs are referred to as II through 18. In 
addition, logic specification 9002 also includes I/O request charts including an extend request 
chart 9030 and a retract request chart 9032 corresponding to extend and retract requests 9031, 
9033, respectively. 

[00237] Extend chart 9030 includes a sequence section 9034 and a properties section 

9036. Properties Section 9036 is explained below. Sequence section 9034 includes a bar 
chart 9038 including a separate bar for each of the inputs and outputs in the I/O tables 8510a, 
8510b, 8510c, 8510d, 8610 and 8710. Thus, bar chart 9038 includes bars 9040 through 9043 
corresponding to I/O table 8610, bars 9044 and 9045 corresponding to I/O table 8710 and 
bars 9046 and 9047 corresponding to I/O table 8510 and so on. Note that chart 9038 is 
separated into six sections corresponding to tables 8610 and 8710 for illustrative purposes 
only and would more likely appear as a single table. 

[00238] The extend clamp request begins at the left edge 9048 of chart 9038 and bars 

9040 through 9047 indicate the I/O combinations during an extend clamp request. Chart 
9038 is divided into three separate I/O combinations named "all retracted", "intermediate" and 
"all extended". Initially, referring only to the first cylindicator 9425, at left edge 9048, the 
retracted proximity input signal (bar 9046) is active indicating that the cylindicator piston is 
in the retracted position. To extend the piston, at edge 9048, both terminals of the two- 
position valve extend solenoid and both terminals of the spring return valve extend solenoid 
are activated (see bars 9040, 9041, 9044 and 9045). For a short time the all retracted 
conditions persist until the retract proximity sensor no longer senses the cylindicator piston. 
[00239] During the period when neither the extended nor retracted sensors sense the 

cylindicator piston, the intermediate conditions exist. During this period, the extend 
solenoids of each of the two-position and spring-return valves remain excited (see bars 9040, 
9041, 9044 and 9045) so that the piston and clamp surface secured thereto continue to move 
toward the extended position. 
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[00240] Eventually the extended proximity sensor senses the cylindicator piston and 

generates an active input (see bar 9047) and the all extended conditions occur. During this 
time and until the extend command subsides, each of the valve extend solenoids remain 
activated. Similar input conditions occur for cylindicators 9427, 9429 and 9431 during an 
extend request. 

[00241] Retract chart 9032 also includes a sequence section 9064 and a properties 

section 9066. Properties section 9066 is explained below. Sequence section 9064 includes a 
bar chart 9068 including a separate bar for each of the inputs and outputs in I/O tables 8510a- 
8510d, 8610 and 8710, respectively. Once again, chart 9068 is separated into six sections 
only for illustrative purposes and would more likely appear as a single table. 
[00242] The retract clamp request begins at the left edge 9070 of chart 9068 and the 

bars of chart 9068 indicate I/O combinations during a retract clamp request. Chart 9068 is 
again divided into three separate I/O sections named "all extended", "intermediate" and "all 
retracted". Initially, referring only to cylindicator 9425, at left edge 9070, the extended 
proximity input signal is active (see bar 9071) indicating that the cylindicator piston is in the 
extended position. To retract the piston, at edge 9070, both terminals of the two-position 
valve retract solenoid ( see bars 9073 and 9075) are activated. For a short time the all 
extended conditions persist until the extend proximity sensor no longer senses the 
cylindicator piston. 

[00243] During the period when neither the extended nor retracted sensors sense the 

cylindicator piston, the intermediate conditions exist. During this period, the retract solenoid 
of the two-position valve remains excited so that the piston and clamp surface secured thereto 
continue to move toward the retracted position. 

[00244] Eventually the retracted proximity sensor senses the cylindicator piston and 

generates an active input and the all retracted conditions occur. During this time and until the 
retract command subsides, the two-position valve retract solenoid remains activated. Similar 
input conditions occur for cylindicators 9427, 9429 and 943 1 during an extend request. 
[00245] It is also contemplated that a resource editor will configure an interface screen 

which resembles the image illustrated in Fig. 85. It is contemplated that resource editor is 
useable to parameterize unique CA instances as will be explained in more detail below. 
[00246] Thus, logic specification 9002 defines I/O combinations during each possible 

request for a mechanical resource which is associated with the CA. In the case of the 
exemplary clamp, the requests include extend and retract requests including the sequences of 
I/O combinations illustrated in Fig. 85. 
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[00247] ii. Schematic Specification 

Referring again to Figs. 84 and 85 and also to Fig. 85A schematic specification 9004 
includes a table 8001 including a list 8003 of the control devices in logic section 9002. The 
list 8003 includes devices which are optional in the CA 9000 as will be explained in more 
detail below. In the present example optional devices include the spring return valve 9423 
and the second through fourth cylindicators 9427 through 9431. 
[00248] Hi. HMI Specification 

Referring to Fig. 84, HMI specification 9006 may take any of several different forms. 
Referring also to Fig. 86, in a preferred embodiment HMI specification 9006 includes an 
HMI specification table 9460. Consistent with the present example, table 9460 includes 
information specifying all possible monitorable and controllable I/O for the lstclamps CA 
instance. To this end, table 9460 includes a device column 9462, a monitorable I/O column 
9464 and a controllable output/request column 9466. Device column 9462 includes a listing 
of all possible control devices which can be included in a particular assembly. In the present 
example, possible lstclamps control devices include two-position valve 9421, spring return 
valve 9423 and first through fourth cylindicators 9425, 9427, 9429 and 9431, respectively. 
[00249] I/O column 9464 lists all monitorable I/O corresponding to control devices in 

column 9462. To this end, all of the outputs corresponding to two position valve 9468 are 
monitorable and therefore, each of those outputs (i.e. Ol, 02, 03, 04) are listed in column 
9464 in the row corresponding to valve 9421 . Both outputs OS and 06 of spring return valve 
9470 are monitorable and therefore, each of those outputs appears in column 9464. First, 
cylindicator 9425 includes two outputs II and 12, each of which are monitorable, and each of 
which appears in column 9464 in the row corresponding to first cylindicator 9425. Similarly 
cylindicators 9427, 9429 and 9431 each have two inputs which are monitorable and which 
appear in column 9464. 

[00250] Controllable outputs/requests column 9466 includes a list of all outputs 

corresponding to the control devices in column 9462 which are potentially manually 
controllable via an HMI. To this end, all of the two position valve outputs Ol, 02, 03 and 
04 are provided in column 9466 in the row corresponding to valve 9421. Both outputs 05 
and 06 of spring return valve 9423 are included in column 9466. None of cylindicators 
9425-9431 include outputs and therefore blanks corresponding to each of the cylindicators 
appear in column 9466. 

[00251] In addition to controllable outputs, potentially manually controllable requests 

are also provided in column 9466. In the present case, there are only two requests which 
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correspond to the lstclamps CA instance including extend request 9031 and retract request 
9033. Each of requests 903 1 and 9033 correspond to the similarly named requests in logic 
specification 9002 ( see Fig. 85) and each is listed in column 9466. 

[00252] When any of the outputs or requests in column 9466 is selected for manual 

control, a manual control request 9035 is also selected. Subsequently, when an HMI is 

configured, the HMI provides means for controlling each of the selected outputs and selected 

requests in column 9466 as will be explained in more detail below and provides means for 

observing each of the selected inputs. Referring to Figs. 85 and 86, it should be 

appreciated that table 9460 includes a large number of monitorable I/O and controllable 

outputs and requests. While such an extensive table 9460 is possible for each CA, whether or 

not table 9460 is extensive is a matter of choice for the engineer who designs the initial CA 

template. For example, the engineer designing the initial CA template may have, instead of 

providing an exhaustive table 9460, provided a table wherein only cylindicator inputs are 

monitorable and the valve outputs Ol through 06 would not be monitorable. Similarly, the i 

engineering designing the template may have decided that only the extend and retract 

requests 9490, 9492, respectively, should be controllable and that the outputs for the valves 

9468 and 9470 should not be controllable. 

[00253] In addition, it should be appreciated that table 9460 is simply a data construct 

for keeping track of selected control devices and corresponding selected monitorable I/O and 
controllable outputs and requests. It is contemplated that other interface tools to be described 
below are used to select and deselect control assemblies and monitorable and controllable 
signals and requests and that table 9460 is simply used to track selection and de-selection 
facilitated via the other tools. 
[00254] iv. Diagnostic Specification 

Referring again to Fig. 84, diagnostic specification 9008 serves as a repository for 
control device diagnostic rules which have been designed into the CA template by the 
engineer who configured the template. Referring also to Fig. 87, diagnostic specification 
9008 includes a diagnostic specification table 9600. Table 9600 includes information 
specifying all possible diagnostic requirements and corresponding activities which may be 
selected for support by a subsequently compiled execution code. Table 9600 includes three 
columns including a device/request column 9602, a requirement column 9604 and an activity 
column 9606. 

[00255] Column 9602 includes a list of devices which include built-in diagnostics. In 

the present case, first clamps includes at least a first cylindicator 9425 which supports 
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diagnostics. Referring again to Fig. 81, when a failure condition occurs wherein both the 
extended and retracted proximity sensors indicate presence of a cylindicator piston ( see 
5418), the diagnostics portion of the control device should indicate, via an HMI, the text 
"cylindicator sensor failure." Thus, first cylindicator 9425 is listed within column 9602. 
Similarly, each of the second, third and fourth cylindicators also correspond to diagnostic 
messaging when a failure condition occurs. Therefore, each of the second, third and fourth 
cylindicators 9610, 9612 and 9614 appear in column 9602. 

[00256] In addition to the cylindicators, exemplary requests associated with 

"interesting conditions" are also provided in column 9602. The exemplary requests include 
extend and retract requests 9616 and 9618 corresponding to the 1st cylindicator 9425 input 
signals. 

[00257] Requirement column 9604 indicates the specific diagnostic condition which 

must occur for corresponding diagnostic activity in column 9606 to take place. Thus, for 
example, the requirement in column 9604 corresponding to first cylindicator 9425 is a failure 
condition 9622 (i.e. each of the extended and retracted proximity sensors in Fig. 81 must 
indicate piston location at the same time). In this case, referring to Figs. 87 and 81, the 
activity in column 9606 corresponding to failure 9622 is to provide text 8517 indicating 
"cylindicator sensor failure". Similar requirements and activities correspond to each of the 
second, third and fourth cylindicators 9427, 9429 and 943 1 , respectively. 
[00258] Referring still to Fig. 87, the requirement 9624 corresponding to the extend 

request for first cylindicator 9425 is that input II remain passive. When input II remains 
passive after an extend request is issued, this indicates that the extended proximity sensor 
does not generate an active input signal II and therefore, for some reason, an error in the 
system has occurred. The activity corresponding to a passive input II is to indicate an error 
9626. A similar requirement corresponds to the retract request for cylinder CI as illustrated. 
[00259] It should be appreciated that, while several diagnostics requirements and 

activities have been provided in table 9600, table 9600 is by no means exhaustive and other 
diagnostics devices and requests and corresponding requirements could be specified and, 
certainly, other activities could also be specified. Thus, table 9600 is meant to be exemplary 
only and not exhaustive. 

[00260] One particularly useful type of diagnostics which is preferably included in the 

diagnostics specification is referred to as "status based" or simply "status" diagnostics. Status 
diagnostics includes diagnostics which, instead of providing a likely diagnosis of a 
specifically identified abnormal or interesting condition, simply indicates the next expected 
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event in a control process. Thus, when a line shuts down because of a malfunction, an 
operator can determine the next event and, based thereon, can typically determine how to 
eliminate the condition which caused the line to stop. 

[00261] One way to facilitate status based diagnostics is for a programmer to go 

through an entire RLL program and, for each event which occurs during the program, provide 
status code which, prior to the even occurring and subsequent to the occurrence of a 
preceding event, indicates the status of the next event to occur via a displayed text message. 
Unfortunately, the programming task of providing such diagnostic code is so time consuming 
and complex that such a task is impractical and is not attempted despite the advantages which 
would result. 

[00262] Importantly, the reusable CA model for programming, execution logic and 

diagnostics can be used to facilitate status based diagnostics programming. This is because 
each CA diagnostics specification can include status based diagnostic messages for each 
event which occurs during one of the CA requests. Each time a new instance of a CA is 
instantiated, a CA request is sequenced in a control bar chart and the requests are compiled, 
the code supporting the status based diagnostics messages can be duplicated and interspersed 
throughout the execution logic code. In this regard, the status based code is added to the 
execution code and has nothing to do with operation of the execution code. The status based 
code simply identifies the next event to occur and then generates a text message for visual 
display indicating the next event to occur. Once the next event to occur has been achieved, 
the diagnostics displays the next event to occur and so on. 

[00263] Which events should be reported is a matter of designer choice. For example, 

for a specific request, several events may take place. For instance, to extend a clamp, a first 
event may be extension of a valve and a second event may be extension of a cylindicator 
associated with the clamp. In this case, either one or both of the events corresponding to the 
request may be supported by status based diagnostics. In one embodiment only termination 
events are supported by status based diagnostics where termination events are the last events 
which occur in a request and where commencement of subsequent requests depends on 
completion of the termination events. In other embodiments intermediate events (i.e. non- 
termination events) are also supported. 

[00264] Referring also to Fig. 87A, an exemplary status based diagnostics specification 

3501 corresponding to the 1st clamps CA is illustrated. Specification 3501 includes a 
specification table 3503 including information specifying all 1st clamps CA requests and all 
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request events. To this end, table 3503 includes a request column 3505, a requirement 
column 3507 and an activity column 3509. 

[00265] Column 3505 includes a list of all 1st clamps CA requests. Referring also to 

Fig. 85, 1st clamps includes only two requests including extend and retract requests 9031 and 
9033, respectively and therefore extend and retract requests 351 1 and 3513, respectively, 
appear in column 3505. 

[00266] Requirements column 3507 include consecutive 1/0 combinations which 

correspond to events which must occur during an associated request (e.g. in this case an 
extend or retract request). For example, referring to Figs. 85 and 87A, when an extend 9031 
1st clamps request is made first, two position valve 9421 must be activated. Valve 9421 is 
activated when outputs 01 and 02 are high and outputs 03 and 04 are low. Thus, the 
requirement for two-position valve activation is 01=1; 02=1; 03=0 and 04=0. All of the other 
1st clamps 1/0 have nothing to do with the status (i.e., active or inactive) of two-position 
valve 9421. In column 3507 other 1/0 for which the status is not important for a specific 
event are identified as "don't care" 1/0 by a " - Thus, the requirement for the two-position 
valve extend event is 1/0 combination 3515. 

[00267] Referring still to Figs. 85 and 87A, the next event to occur during the 1st 

clamps extend request is a spring return valve extend event which occurs when outputs 05 
and 06 are high. The status of all other 1st clamp 1/0 is unimportant with respect to the spring 
return valve extend event. The 1/0 combination requirement in column 3507 for the spring 
return valve extend event is identified by numeral 3517. 

[00268] Note that in reality, both two-position valve 9421 and spring-return valve 9423 

would achieve their respective extend states simultaneously. Nevertheless, by providing 
status based diagnostics which checks events consecutively, each event is reported separately 
and if one event does not occur, the single event which does not occur is reported for an 
operators observation. 

[00269] Referring again to Figs. 85 and 87A, the next event to occur during a 1st 

clamps extend request is a 1st cylindicator extended event which occurs when input II is high 
and input 12 is low. This event corresponds to 1/0 combination requirement 3519 in column 
3507. Although not numbered, column 3507 includes other 1/0 combination requirements 
which correspond to extended second, third and fourth cylindicators 9427, 9429 and 9431, 
respectively. 
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[00270] Similarly, column 3507 also includes I/O combination requirements 

corresponding to consecutive events which occur during the 1st clamps retract request ( see 
9033 in Fig. 85). For instance, a two-position retract event is identified by numeral 3521. 
[00271] Column 3509 includes a single activity corresponding to each requirement in 

column 3507. For example, activity 3523 corresponds to the two-position value extend event 
requirement 3515 and specifies text "two-position valve extend" to be displayed. Similarly, 
activity 3525 specifying text "spring-return valve extend" corresponding to the spring-return 
valve extend event requirement 3517 and so on. 

[00272] Activities in column 3523 are performed from the time when a previous event 

is completed until the time the corresponding requirement in column 3507 occurs. For 
example, after a request prior to a 1st clamps extend request has been completed, message 
"two-position valve extend" is displayed until 1/0 combination requirement 3515 is achieved. 
After requirement 3515 is achieved message "spring-return valve extend" is displayed until 
requirement 3517 is achieved. After requirement 3517 is achieved message 1st cylindicator 
extended" is displayed and so on. 
[00273] v. Simulation Specification 

Referring again to Fig. 84, simulation specification 9300 is used to facilitate virtual 
three dimensional CAM simulation using real world PLC execution code generated by 
compiling control logic. The execution code specifies I/O for specific control mechanisms 
which in turn control mechanical resources linked thereto. When linked to the control 
mechanisms correctly, the execution code causes a prescribed manufacturing process to be 
performed. 

[00274] It has been recognized that in the virtual world, while the mechanical 

resources which form a manufacturing line and their possible movements can be represented 
by video clips of the resources in operation, unfortunately, control mechanisms have no 
virtual representation. Thus, while the execution code specifies I/O for controlling virtual 
mechanical resources via control mechanisms, because there are no virtual control 
mechanisms, there is a disconnect between the execution code and the virtual mechanical 
resources. 

[00275] Exemplary specification 9300 effectively maps the PLC outputs to 

corresponding video clips of the virtual mechanical resources. In addition, simulation 
specification 9300 also maps signals corresponding to specific occurrences in the video clips 
back to the PLC as PLC inputs. 
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[00276] Referring now to Fig. 88, an exemplary simulation specification 9300 

corresponding to lstclamps logic specifications 9002 is illustrated and includes video tables 
and feedback tables for each of the four possible cylindicators 9425-9431. Thus, for the first 
cylindicator 9425, specification 9300 includes video table 9302 and feedback table 9304. For 
the second cylindicator 9427, specification 9300 includes video table 9303 and feedback 
table 9305 and, although not illustrated, similar video and feedback tables are provided for 
third and fourth cylindicators 9429 and 9431, respectively. Each of the video tables is similar 
and therefore, to simplify this explanation, only tables 9302 and 9304 are explained here in 
detail. 

[00277] Video table 9302 includes an I/O combination column 9306 and a video clip 

column 9308. Combination column 9306 includes an I/O row 9310 which lists all of the I/O 
in logic specification 9002 which is associated with operation of the first cylindicator 9425 to 
move an associated clamp. Thus, row 9310 includes outputs 01 through 06 and inputs II and 
12. In the video and feedback tables corresponding to the second, third and fourth 
cylindicators 9427-9431, combination columns would be essentially identical to column 9306 
except that inputs II and 12 would be 13, 14; 15, 16; and 17, 18, respectively. 
[00278] Referring still to Fig. 88, below row 9310 is a list of I/O combinations which 

includes every possible I/O combination corresponding to the I/O in row 93 10. In the column 
9306 list, a "1" indicates an active signal, a "0" indicates a passive signal and a "-" indicates a 
"don't care" condition. Thus, for example, the first I/O combination 9312 includes active 
outputs Ol, 02, 05 and 06, passive outputs 03 and 04, a passive input II and the state of 
input 12 does not matter. 

[00279] Video clip column 9308 includes a list of video clip indicators corresponding 

to the I/O combinations in the rows of column 9306. In the present example (i.e. a clamp 
associated with the first cylindicators), only three possible video clips can occur. The first 
video clip identified by "1" corresponds to a video illustrating a clamp extending. A second 
video clip identified by "2" corresponds to a video illustrating a clamp retracting. The third 
video clip "3" corresponds to a video illustrating a stationary clamp. 
[00280] Referring to Figs. 85 and 88, the first combination 9312 corresponds to an 

extend request in logic specification 9002 and, as desired, is associated with the extend video 
clip 1 (9314). The second I/O combination 9316 in column 9306 includes outputs which 
correspond to an extend request in specification 9002. However, input II is also active 
indicating that the extend video has already occurred. In this case, the combination 9316 
corresponds to the stationary video 3 (9318). Continuing, the fourth I/O combination 9320 
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includes all passive outputs and a passive second input 12. In the case of first clamps, a 
passive input 12 indicates that the clamp is not yet in the retracted position. In addition, 
because all outputs Ol through 06 are passive, the spring in the spring return valve should 
force the clamp into the retracted position. Therefore, the video clip corresponding to fourth 
I/O combination 9320 is clip 2 (9322) which shows the clamp retracting. 
[00281] Thus, table 9302 receives PLC VO combinations corresponding to a first 

clamp to be controlled and maps each combination to a specific video clip which illustrates 
what a clamp in the real world would be expected to do as a result of the specific I/O 
combination. Video tables for the second, third and fourth clamps which are controllable via 
the first clamps CA operate in a similar fashion. 

[00282] Referring still to Fig. 88, feedback table 9304 includes both an event column 

9324 and a feedback column 9326. Event column 9324 includes events corresponding to 
specific occurrences in video clips which should be linked to PLC inputs. In the present 
example, the lstclamps inputs include extended proximity and retracted proximity signals II 
and 12 which should change from passive to active when an associated clamp video reaches 
fully extended and fully retracted positions, respectively. In the case of the clamp videos, the 
fully extended position is achieved at the end of video clip 1 and the fully retracted position is 
achieved at the end of video clip 2. Therefore, the events in column 9324 include video clip 

I complete and video clip 2 complete. 

[00283] Feedback column 9326 includes feedback input signals for the PLC 

corresponding to each event in column 9324. For example, at the end of video clip 1, input 

II is set equal to 1 and input 12 is set equal to 0. Similarly, at the end of video clip 2 when 
the clamp achieves the fully retracted position, input II is set equal to 0 and input 12 is set 
equal to 1 indicating a fully retracted clamp. 

[00284] It should be appreciated that the tables 9302 and 9304 in Fig. 88 are not 

exhaustive and that other combinations in corresponding video clips could be added to table 
9302 and other events and corresponding feedback could be added to table 9304. 
[00285] In addition, it should be appreciated that, instead of being used with a video 

module which plays video clips, the simulation specification may be used in conjunction with 
a CAD or CAM system which can simulate three-dimensional movement of three- 
dimensional virtual mechanical resources on the display of a work station. In this case 
instead of mapping I/O combinations to specific video clips, the I/O combinations may be 
mapped to specific requests in a mechanical resource timing diagram which in turn cause the 
CAD or CAM system to display corresponding mechanical resources in operation. In 
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addition, in this case, instead of linking feedback events to specific occurrences in video 
clips, the feedback events would be linked to specific occurrences during CAD or CAM 
simulation. Moreover, other types of simulation specification are contemplated and are 
described in more detail below. 
[00286] b. CA Parameterization 

While it would be preferable if all controls information in a CA were completely 
rigid, unfortunately, as indicated in the Background section above, such a system would 
likely result in an unworkably large number of CAS. For example, for clamps, if there were 
five clamp CA features in addition to basic (i.e., a valve and a cylinder) clamp CA 
requirements, the number of different feature combinations would require a huge number of 
separate clamp CAS. 

[00287] To avoid requiring a massive CA template library, the inventive CA templates 

have been designed to strike a compromise between parameterization and permanently 
specified controls information. While each of the CAS include predefined controls 
information, some or all of the CAS may include information which can be "parameterized" 
or "customized". In this context the term "parameterized" means that a portion of the CA can 
be modified so that CA features accommodate specific design requirements. 
[00288] While many schemes for facilitating parameterization are contemplated by the 

present invention, in the interest of simplifying this explanation a single parameterization 
scheme will be described. In the exemplary scheme each CA template defines all of the 
control information which is required to support a maximum number of control devices and 
corresponding HMI characteristics, diagnostics and simulation. However, at least some of 
the control information defined in each parameterizable CA is selectable and de-selectable 
via parameterization tools to be described. When CA information is selected, the information 
is said to be instantiated in the specific CA instance and is subsequently used by a compiler to 
generate a control execution code, to configure an HMI, to generate schematics and to 
provide simulation tools. Information which is not selected and instantiated is said to "exist" 
in the CA instance but is not subsequently used during compilation to generate execution 
code, configure an HMI, provide control system schematics or to support virtual system 
simulation. 

[00289] Generally, two types of parameterization referred to as "property setting" and 

"feature selection" are contemplated. Referring again to Fig. 85, property setting 
parameterization involves properties sections 9036 and 9066. Properties section 9036 
includes indicators for indicating specific properties of the lstclamps CA instance extend 
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request. To this end, the indicators include a latch set 9050, a restart set 9052 and an inverse 
request set 9054. Latch set 9050 indicates whether a latch (i.e. a switch) should be set at the 
end of the extend request. When a latch is set, the latch can be used as a trigger or a 
condition for other system requests. The latch set 9050 is set when a flag (i.e. a check) 
appears in the flag box 9051. In Fig. 85 the latch set is not set. 

[00290] Restart set 9052 indicates whether or not the extend request is restartable. 

Restartable means that during execution of a request, if another identical request is initiated, 
the second request can restart the request cycle. Some requests cannot be restarted. For 
example, a particular sequence of robot movements most often would not be restartable 
without modifying an end result. For instance, if a request requires a robot to move a 
welding point 12 inches forward and 10 inches to the left during a request, after the robot 
moves 8 inches forward, if the request was restarted, the end result would be incorrect. 
[00291] Referring still to Fig. 85, in the case of the extend request cycle indicated by 

chart 9038, it makes no difference during an extend request if another extend request is 
received, the second extend request can restart the cycle. Thus, a check in a "restartable" flag 
box 9053 indicates a restartable request. 

[00292] Inverse request set 9054 indicates the inverse request for the extend request. 

Virtually all requests include an inverse request which is the inverse of the request which 
returns a mechanical resource back to an initial state. For example, in the case of a clamp, 
the inverse of an extend request is often a retract request. In the case of a robot, the inverse 
of a request moving 12 inches forward and 8 inches to the left may be to move 8 inches to the 
right and 12 inches rearward. While only extend and retract requests are illustrated in Fig. 
85, mechanical resources other than a clamp may have many more than two requests 
specified in their logic specifications 9002. For example, in the case of a robot, a robot may 
have ten different requests which can be called to cause the robot to cycle through ten 
different movement sequences. In this case, five of the requests may by the inverse requests 
for the other five requests and the inverse requests would be indicated using the inverse 
request set 9054 and an accompanying window 9056. In the present case, window 9052 
indicates the inverse request as the retract request specified by retract request chart 9032. 
Referring again to Fig. 85. Properties section 9066 is similar to section 9036 and therefore 
will not be explained again in detail. The main difference between sections 9036 and 9066 is 
that the inverse request set 9084 in section 9066 indicates the extend request instead of the 
retract request. 
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[00293] The lstclamps request properties in properties sections 9036 and 9066 are an 

example of features which are parameterizable via property setting. Thus, when the 
lstclamps CA instance is instantiated, the control engineer can specify if a latch should be set 
at the end of the extend request ( see latch set 9050), if the extend request is to be restartable 
(see restart set 9052) and which request is the inverse of the extend request ( see inverse 
request set 9054). Similar parameterization is enabled in properties section 9066. 
[00294] The second type of parameterization, feature selection, as the name implies, 

simply provides a control engineer the option to select or de-select optional CA control 
features for compilation which, although desired in certain applications, are not required in 
all applications. To this end, some of the devices in CA logic specification 9002 are required 
and others of the listed devices are not necessarily required for the lstclamps CA to operate 
properly. 

[00295] In addition, some of the control devices are included in the CA template as 

default devices whereas others of the listed control devices may optionally be added to the 
CA as required. Optional default control devices can be deselected so that they are 
effectively removed from a specific CA instance. For example, the devices in specification 
9002 include three default control assemblies including two position valve 9421, spring 
return valve 9423 and 1st cylindicator 9425. Of the three default control devices 9421, 9423 
and 9425, it is assumed that only the two position valve 9421 and first cylindicator 9425 are 
required, the spring return valve 9423 being optional. 

[00296] Throughout Figs. 85, 85 A, 86, 87, 87A and 88, a plurality of flag boxes (e.g. 

9480a, 9482a, 9484a, 9486a, 9480b, 9480c, etc.) are provided, each of which corresponds to 
a CA device or characteristic which may be selected or de-selected to parameterize a specific 
CA instance. Flag boxes which include a flag (e.g. see box 9480a in Fig. 85) indicate 
selection or designation and boxes which are clear (e.g. see box 9991 in Fig. 86) indicate un- 
selected or un-designated devices or characteristics. 

[00297] Generally there are two different types of flag boxes, designation boxes and 

selection boxes. On one hand, a designation box is used to designate an associated device, 
characteristic or characteristic set as an item which is later presented as a selectable item for 
additional parameterization. Thus, a characteristic or characteristic set which is designated 
by a flag in a designation box is not instantiated but is later presented for possible 
instantiation. On the other hand, a selection box is used to select and instantiate a 
corresponding characteristic for subsequent compilation. 
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[00298] Referring again to Fig. 85, to indicate the optional nature of spring return 

valve 9423, a selection box 9480a is provided adjacent valve 9423. Initially, as value 9423 is 
a default control device, a flag mark (i.e. check) appears within box 9480a. Because each of 
control devices 9468 and 9472 are required, flag boxes are not provided adjacent those two 
control devices in column 9462. It is contemplated that a tool will be provided for de- 
selecting valve 9423 by removing the flag from box 9480a. One such tool is described 
below. 

[00299] In addition to default control devices 9421, 9423 and 9425, the devices in the 

"SafeBulkHeadClampSet" CA template logic specification 9002 also includes three optional 
control devices including second, third, and fourth cylindicators 9427, 9429 and 943 1 . 
Because each of cylindicators 9427-9431 can optionally be selected or deselected to remove, 
respectively, the cylindicators from the control assembly, selection boxes 9482a, 9484a and 
9486a are provided adjacent each of the cylindicators 9427, 9429 and 9431, respectively. 
While flags are provided in boxes 9482a, 9484a and 9486a, initially, because each of 
cylindicators 9427-943 1 are not default control devices, flags would not be provided in boxes 
9482a, 9484a and 9486a. If cylindicators 9427-9431 are selected flags are placed within 
corresponding selection boxes to indicate selection. Fig. 85 reflects the state of boxes 9482a, 
9484a and 9486a after selection of cylindicators 9427-9431. 

[00300] Referring to Figs. 85 and 85 A, separate selection boxes 9480f, 9482f, 9484f 

and 9486f which correspond to selection boxes 9480a, 9482a, 9484a and 9486a, respectively, 
are provided adjacent representations" spring return valve" 9423, "2nd cylindicator" 9427, 
"3rd cylindicator" 9429 and "4th cylindicator" 9431, respectively. As described below, when 
a selection or de-selection is made in specification 9002, selection ripples through schematics 
specification 9004 providing flags in corresponding selection boxes 9480f, 9482f, 9484f and 
9486f. As indicated above, flags in any of boxes 9480f-9486f indicate that subsequently, 
when the schematic is compiled and constructed for the lstclamps CA instance, the compiler 
must include representations in the schematic for corresponding control devices (e.g. spring 
return valve 9423, 2nd cylindicator 9427, etc.) 

[00301] Initially, because spring return valve 9423 is a default control device, a flag 

appears in box 9480f. Similarly, because each of cylindicators 9427, 9429 and 9431 are not 
default devices, initially no flags appear in boxes 9482f, 9484f and 9486f. Fig. 85 A shows 
the state of boxes 9482f, 9484f and 9486f after corresponding cylinders have been selected 
for inclusion in the 1 stclamps CA instance. 
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[00302] Referring to Figs. 85 and 86, separate designation boxes 9480b, 9482b, 9484b 

and 9486b which correspond to selection boxes 9480a, 9482a, 9484a and 9486a, respectively, 
are provided next to the representations "spring return valve" 9423, "cylindicator-2" 9427, 
"cylindicator-3" 9429 and "cylindicator 4" 9431, respectively. As described below, when a 
selection or de-selection is made in specification 9002, the selection ripples through HMI 
table 9460 providing flags in corresponding designation boxes 9480b, 9482b, 9484b and 
9486b. Boxes 9482b, 9484b and 9486b include flags indicating designation. 
[00303] In addition, a separate selection box (e.g. 9991) is provided under each of 

outputs Ol through 04 for indicating selection of those outputs to be supported by a 
corresponding HMI. For each of outputs Ol through 04 which is selected to be monitored 
via an HMI, some type of an HMI indicator is specified during subsequent compilation which 
corresponds to the selected output. As illustrated in Fig. 86, none of the output selection 
boxes includes a flag and therefore none of the outputs are selected. Selection boxes (e.g. 
9493, 9495) are also provided for outputs 05 and 06 and for each input 11-18 in column 9464. 
As illustrated, boxes 9493 and 9495 include flags and therefore have been selected. 
[00304] Referring still to Fig. 86, as with the outputs listed in column 9464, a separate 

selection box is provided for each of outputs in column 9466 to indicate whether or not the 
corresponding outputs are selected to be included in the HMI. As illustrated, none of the 
outputs are presently selected (i.e. the selection boxes are empty). Also, selection boxes are 
provided each of outputs 05 and 06 in column 9466. Selection boxes 9490, 9492 are also 
provided adjacent "extend" and "retract" requests in column 9466. Boxes 9490 and 9492 
include flags indicating selection. 

[00305] Referring to Figs. 85 and 87, separate designation boxes 9482c, 9484c and 

9486c which correspond to boxes 9482a, 9484a and 9486a, respectively, are provided next to 
cylindicators 9427, 9429 and 9431, respectively. As described below, when a selection or de- 
selection is made in specification 9002, the selection ripples through diagnostics table 9600 
providing a flag in a corresponding designation box 9482c, 9484c or 9486c. In addition, 
selection boxes 2001, 2002, 2003, etc. are provided next to each requirement in list 9604 to 
enable further parameterization as described below. Each of boxes 9482c, 9484c and 9486c 
include flags indicating designation while box 2001 includes a flag indicating selection. 
[00306] Referring to Fig. 87A, where a status based diagnostics specification is 

employed, separate designation boxes, 9480g, 9482g, 9484g and 9486g which correspond to 
boxes 9480a, 9482a, 9484a and 9486a (see Fig. 85), respectively, are provided next to spring 
return valve extend requirement 3520 and so on. Similarly, boxes 9480g, 9482g, 9484g and 
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9486g are provided next to return request event requirements which are associated with 
spring-return valve 9423, second cylindicator 9427, third cylindicator 9429 and fourth 
cylindicator 9429. Once again, when a selection or de-selection is made in specification 
9002. The selection ripples through diagnostics table 3503 providing or eliminating a flag in 
corresponding designation boxes 9480g, 9482g, 9484g and/or 9486g. 
[00307] With respect to status based diagnostics, when a designation box is blank, 

upon compilation status based diagnostics code is not provided for a corresponding event. 
For example, referring to Figs. 85 and 87A, where box 9480a is deselected to remove the flag 
therein, the de-selection ripples through table 3501 and removes the flag from boxes 9480g. 
Then, upon compilation, the status based diagnostics specifies that after requirement 3515 is 
achieved, requirement 3519 corresponds to the next event and the displayed status based 
diagnostics message is "Ist-cylindicator extended." 

[00308] Referring to Figs. 85 and 88, selection boxes 9480c, 9480d and 9480e which 

correspond to box 9480a are provided in video table 9302. Box 9480c corresponds to column 
9037 below output 05. When the spring return valve 9423 is selected, output 05 exists and 
therefore should affect table 9302. However, when valve 9423 is deselected, output 05 does 
not exist and hence must not affect the video to be displayed. An empty selection box 9480c 
renders data in column 9037 under output 05 ineffective. The remaining I/O combinations 
are still effective for mapping purposes. Box 9480d has a similar relationship to output 06 
and column 9039 therebelow. 

[00309] Box 9480e corresponds to the I/O combination 9320 to the right thereof in 

column 9306. In the present example, if spring return valve 9423 is de-selected, certain I/O 
combinations, including the combination to the right of box 9480e, are incorrect and 
therefore should not affect the video to be displayed. An empty selection box 9480e renders 
I/O combination 9320 to the right thereof ineffective. 

[00310] Referring still to Figs. 85 and 88, selection boxes 9482d and 9482e are 

provided in tables 9303 and 9305 which correspond to box 9482a. When cylindicator 9427 is 
selected in specification 9002, simulation tables like tables 9302 and 9304 must be provided 
for the second cylindicator 9427. To this end, flags in boxes 9482d and 9482e select and 
instantiate tables 9303 and 9305 for subsequent compilation. Boxes 9482d and 9482e each 
include a flag and therefore indicate selection of corresponding tables 9303 and 9305, 
respectively. Although not illustrated, similar selection boxes are provided for video and 
feedback tables corresponding to third and fourth cylindicators 9429 and 9431, respectively. 
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[0031 1] Referring to Fig. 85, as indicated above, spring return valve 9423 is an initial 

default control device but is optional. Referring to Figs. 84 and 85 if valve 9423 is de- 
selected using an editor described below and as indicated by removing the flag from box 
9480a, de-selection ripples through each CA specification 9004, 9006, 9008 and 9300 to 
modify tables therein to reflect de-selection. 

[00312] To this end, referring to Figs. 85 and 85A, initially a flag appears in box 9480f 

indicating a default device and that spring return valve 9423 must be represented in a CA 
schematic representation upon compilation. However, when the flag is removed from box 
9480a (see Fig. 85), the flag in box 9480f is also removed. When the flag in box 9480f is 
removed, spring return valve 9423 is de-selected and, upon compilation, will not be 
represented in the CA schematic. Referring to Figs. 85 and 86, initially, a flag appears in box 
9480b indicating a default control device and indicating that I/O in columns 9464 and 9466 
will subsequently be presented for selection and instantiation via an HMI editor (i.e., 
corresponding I/O in columns 9464 and 9466 has been designated for subsequent possible 
selection and instantiation). However, when the flag is removed from flag box 9480a in logic 
specification 9002, the flag in box 9480b is also removed. The practical effect of removing 
the flag from box 9480b is that monitorable I/O in column 9464 and controllable output in 
column 9466 corresponding to valve 9423 are undesignated and therefore, upon subsequent 
presentation of monitorable and controllable I/O for selection and instantiation, these I/O are 
not presented. 

[00313] Referring to Fig. 87, diagnostic specification table 9600 does not specify 

diagnostics for the spring return valve and therefore no flags are modified in table 9600 when 
spring return valve 9423 is de-selected in logic specification 9002. 

[00314] Referring to Fig. 88, selection boxes 9480c and 9480d are provided for outputs 

05 and 06 which correspond to spring return valve 9423 and which are associated with flag 
box 9480a. Initially, because valve 9423 is a default control device, flags are provided in 
each of boxes 9480c and 9480d meaning that outputs 05 and 06 in column 9306 are to be 
included in I/O combinations. When the flag is removed from box 9480a, the flags in boxes 
9480c and 9480d are also removed thereby effectively de-selecting and eliminating outputs 
05 and 06 from the combinations in column 9306. 

[00315] In addition, when outputs 05 and 06 are eliminated by de-selection, some of 

the video clips corresponding to combinations in column 9306 may be rendered incorrect. 
For example, referring still to Figs. 85 and 88 and specifically to combination 9320, if spring 
return valve 9423 is de-selected, because the safety spring in the return valve is eliminated, 
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when all of inputs 01 through 04 are passive (i.e. zeros), the clamp linked to the first cylinder 
will remain stationary. For this reason, the retract video clip 9322 is incorrect. Thus, 
selection boxes (one illustrated) 9480e corresponding to combination/video clips which are to 
be de-selected and hence rendered un-instantiated upon de-selection are provided adjacent 
each such combination. Once again, initially a flag appears in box 9480e as spring return 
valve 9423 is a default device. 

[00316] Referring to Fig. 84, all other controls information in CA 9000 is also updated 

when a second cylindicator control device is selected and added to CA 9000 to control a 
second clamp. Referring to Figs. 85 and 86, when a flag is placed in selection box 9482a, a 
flag is also placed in designation box 9482b. A flag in box designation 9482b indicates that 
the monitorable and controllable I/O corresponding to the second cylindicator 3 should be 
subsequently presented for selection and instantiation via an HMI editor. In the present 
example second cylindicator 9427 includes inputs 13 and 14 which are monitorable and 
includes no controllable outputs. 

[00317] Referring to Figs. 85 and 87, when a flag is placed in box 9482a, a 

corresponding flag is placed in designation box 9482c indicating that the requirement and 
activity in the row corresponding to the second cylindicator 9427 should be subsequently 
provided for selection and instantiation via a diagnostics editor. If box 9427 is empty, 
corresponding requirements/activities are not subsequently provided for selection. 
[00318] Referring to Figs. 85 and 88, when a flag is placed in selection box 9482a, 

corresponding flags are placed in selection boxes 9482d and 9482e. Flags in boxes 9482d 
and 9482e select and instantiate tables 9303 and 9305 for subsequent compilation. 
[00319] Referring to Figs. 85, 85 A, 86, 87 and 88, each of the selection boxes 9484a 

and 9486a correspond to designation and selection boxes in each of schematics table 800, 
HMI table 9460, diagnostics table 9600 and simulation specification 9300 and, as with box 
9482a, flags in boxes 9484a and 9486a ripple through tables 800, 9460 and 9600 and through 
specification 9300 to designate (i.e., designate information for subsequent selection) and 
select (i.e., instantiate information for subsequent compilation), respectively. 
[00320] In this manner, any change to logic specification 9002 ripples through other 

specification sections of control assembly 9000. 
[00321] 4. Control Sequence Bar Chart 

CA requests can be sequenced to cause a plurality of mechanical components to 
operate in a specified order to carry out a manufacturing process. Referring to Fig. 89, 
preferably, the sequencing process is accomplished using a control bar chart 9700. Chart 
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9700 includes a control resource column 9702, a requests column 9704 and a bar chart 
diagram 9706 which corresponds to the columns 9702 and 9704. The resources column 9702 
includes a list of CA instances which have been chosen to control the mechanical resources 
(not illustrated) which are associated with a specific manufacturing process. To this end, as 
illustrated, the CAS include controllers, pins, clamps, dumps, locators and so on. One of the 
specified CA instances is the Istclamps CA instance described above which appears twice in 
column 9702 at 9708 and 9709. 

[00322] Requests column 9704 includes a list of requests corresponding to the CAS in 

column 9702. Referring to Figs. 85 and 89, the Istclamps "extend" request 9710 corresponds 
to extend request 9031 in CA logic specification 9002. Similarly, the Istclamps "retract" 
request 971 1 corresponds to retract request 9033 in CA logic specification 9002. 
[00323] Diagram 9706 is temporally spaced along a horizontal axis and includes a 

separate bar for each request in column 9704. For example the bar corresponding to 
Istclamps extend request 9710 is bar 9712. The bars are sequenced from left to right and top 
to bottom according to the order in which the requests associated therewith occur during the 
manufacturing process. For example, in section 9706, the extend request associated with bar 
9712 occurs after the request associated with bar 9716 and just before the request associated 
with bar 9718 and so on. Hereinafter, to simplify this explanation, the bars in Fig. 89 will be 
referred to generally as requests. 

[00324] By selecting and parameterizing CA instances to control each mechanical 

resource in a manufacturer line and sequencing CA instance requests using a control bar chart 
like the chart illustrated in Fig. 89, virtually all of the controls information which is required 
to generate execution code, schematics, HMI code, diagnostics code and simulation tools is 
completely specified. Thereafter, a compiler is used as explained below to generate the 
execution code for simulation and PLC control. 
[00325] B. General Overview of System 

Referring now to Fig. 90, an exemplary system according to the present invention 
includes a plurality of networked components including a CAD system 9800, a resource 
editor 9802, an HMI editor 9804, a diagnostics editor 9806, an enterprise control data base 
9810, a compiler 9812, a PLC 9814, a simulator or core modeling system (CMS) 9816, a 
movie module 9818, an HMI work station 8437, a simulation screen 9820 and a printer 8436. 
System 8458 represents all of the mechanical control mechanisms which are to be controlled 
by PLC 9814. Hereinafter, each of the components, editors or systems in Fig. 90 will be 
explained separately or, where advantageous, in conjunction with other components. 
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[00326] 1. CAD System/Movie Module 

Referring still to Fig. 90, it is contemplated that CAD system 9800 has a plurality of 
capabilities. First, CAD system 9800 is useable to define three dimensional mechanical 
resources such as clamps, robots, mills, and so on. Second, CAD system 9800 is able to 
define model movements and movement ranges and limits. 

[00327] These two capabilities, to define 3D mechanical resources and their ranges of 

motion, enable a process engineer to envision a controls process. In addition, in at least one 
embodiment these two abilities can be combined with simulation specifications to virtually 
simulate a manufacturing process. 

[00328] Third, CAD system 9800 can be used by an engineer to label specific model 

movements or cycles with mechanical resource activity names. Fourth, CAD system 9800 
provides tools which allow an engineer to sequence the named activities. Preferably the 
sequencing is provided using a mechanical resource timing diagram, a tool which is already 
well known within the controls industry. 

[00329] Movie module 9818 includes exemplary video clips or motion pictures of 

mechanical resources traversing through each possible mechanical resource activity required 
during a manufacturing process. For example, in the case of a clamp, the video clips include 
extend and retract clips corresponding to clamp videos showing extend and retract 
movements. The clips also include stationary clips showing corresponding static mechanical 
resources. Video module 9818 is capable of playing a plurality of video clips simultaneously 
and arranged on a display in a manner which reflects actual layout and configured 
relationships of mechanical resources. Module 9818 is linked to screen 9820 for this 
purpose. Module 9818 receives command signals from simulator 9816 indicating clips to 
play. Module 9818 is also capable of recognizing specific occurrences in video clips and 
providing feedback signals to PLC 9814 via CMS 9816 for simulation purposes. 
[00330] At this point, it will be assumed that CAD system 9800 has already been used 

to define all mechanical resources to be used in an exemplary manufacturing process, 
mechanical resource activity cycles have been given activity names and a mechanical timing 
diagram has been provided which is stored in database 9810. 

[00331] Referring now to Fig. 91, a portion of an exemplary mechanical resource 

timing diagram 9650 is illustrated. Diagram 9650 includes a mechanical resource column 
9652, an activities column 9654 and a timing diagram 9656. Resource column 9652 lists all 
of the mechanical resources which a process engineer has specified for an exemplary 
manufacturing process in the order in which corresponding mechanical resource activities 
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will occur. Although not illustrated, most of the mechanical resources will be listed more 
than once in resource column 9652 as most mechanical resources perform more than a single 
activity during a manufacturing process. For example, a clamp will typically extend and 
retract at least once during a manufacturing process and therefore would appear at least once 
for an extend activity and at least a second time for a retract activity. 
[00332] The activity column 9654 includes a list of activities corresponding to the 

mechanical resources of column 9652. For example, with respect to a clamp 9651, a 
specified activity 9653 is "Fixture" meaning that the clamp 9651 should fix or close or extend 
onto a work item. Similarly, a plurality of other clamps are to extend along with clamp 9651, 
the other clamps including, among others, clamps 9655, 9657 and 9659. 
[00333] Timing diagram 9456 is temporarily spaced along a horizontal axis and 

includes a plurality of bars which are arranged in sequential order from left to right and top to 
bottom, a separate bar corresponding to each of the activities in column 9654. Thus, bars 
9658 through 9660 indicate fixture of three pins (i.e., mechanical resources), bar 9661 
indicates a loading activity by a robot gripper, bar 9663 indicates fixture of a dump 9665, bar 
9662 indicates fixture of clamp 9651, and so on. Clamp 9651 does not begin to close until 
after dump 9665 fixture is complete and clamp 965 1 must be closed before an operator loader 
9666 can load (i.e., perform the specified activity 9668). 

[00334] With a complete mechanical timing diagram specified, the inventive resource 

editor and other editors can now be described. 
[00335] 2. Editors 

Referring to Fig. 90, the present invention includes resource editor 9802 and is meant 
to be used with both HMI editor 9804 and a diagnostics editor 9806. Each of the resource, 
HMI and diagnostics editors are described separately. 
[00336] a. Resource Editor 

Referring still to Fig. 90, resource editor 9802, as well as all of the other editors 9804, 
9806 used with the present invention, preferably, is provided via software which runs on a 
work station or the like, enabling a control engineer to use display screen tools such as tables, 
windows and work spaces and a mouse-controlled icon for selecting various buttons and 
pull-down menus to specify controls information with the aid of a CA template library which 
is stored in ECDB 9810. 

[00337] To this end, referring to Fig. 55, an exemplary resource editor image which 

may be displayed on a work station display screen is illustrated. Hereinafter resource editor 
9802 is often referred to as a designer studio. Screen 5500 includes a tool bar 5502 and four 
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work space windows. The work space windows include a mechanical resources window 
5504, a mechanical timing diagram window 5506, a control resources window 5508 and a 
control bar chart window 5510. Tool bar 5502 includes editing tools which will be described 
in more detail below through exemplary use. When a mechanical timing diagram is imported 
into the resource editor environment, the mechanical timing diagram is presented within 
mechanical timing diagram window 5506 and each mechanical resource within the diagram is 
provided within a list inside the mechanical resources window 5504. 
[00338] Initially, it will be assumed that a plurality of different manufacturing 

processes have been defined using CAD system 9800 and that a separate mechanical timing 
diagram corresponding to each one of the defined manufacturing processes is stored in data 
base 9810. Referring now to Fig. 57, a mouse-controlled cursor (not illustrated) can be used 
along with the tool bar 5502 to select one of the stored mechanical resource timing diagrams 
by selecting the manufacturing process name 5512 from a list. Referring also to Fig. 58, once 
a mechanical timing diagram has been selected, the mechanical timing diagram is imported 
into window 5506, and the list of mechanical resources is provided in window 5504. The 
mechanical timing diagram in this case is identified by 5820 while the mechanical resource 
list is identified by 5810. 

[00339] Referring to Figs. 58 and 91, it should be appreciated that the mechanical 

timing diagram 5820 is identical to the diagram 9650. It should also be recognized that only 
a small portion of the mechanical timing diagram is illustrated in window 5506, the diagram 
extending to the right and downward further than window 5506 will allow. In addition, 
diagram 5520 includes a key 5514 above the timing diagram section. Key 5514 indicates 
differently shaded bars corresponding to different types of resources. A dark bar 5516 
corresponds to a mechanical activity, a darkly shaded bar 5518 corresponds to a robot activity 
(an activity for which additional programming is required) and a lightly shaded bar 5520 
corresponds to an activity which must be performed by a human operator. 
[00340] In addition, when a mechanical timing diagram is imported into the resource 

editor environment, resource editor 9802 assumes that a control system is to be defined for 
controlling the mechanical resources in the timing diagram. Therefore, resource editor 9802 
automatically provides a list 5512 of control assemblies in control resources window 5508, 
the list 5512 including all possible control assemblies which may be used to control 
mechanical resources in diagram 5820. Of particular interest in explaining operation and 
features of the present invention, note that one of the CAS in list 5512 is a "safe bulk head 
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clamp set" CA 5540, CA 5540 corresponding to the clamp template described in detail above. 

[00341] Moreover, resource editor 9802 automatically constructs an initial and blank 

control bar chart image 5830 within control bar chart window 5510. Referring to Figs. 58 
and 89, image 5830, like control bar chart 9700, includes a control assembly column 5522, a 
requests column 5524 and a bar chart diagram 5526. While blank diagram 5526 does include 
a timing grid which is initially identical to the grid of mechanical timing diagram 5820 
including identical spaced edges (e.g. 5523, 5527, etc.) and period durations which is helpful 
for subsequent sequencing of CA requests. In addition, editor 9802 provides a key 5528 
above bar chart diagram 5526. Key 5528 specifies four differently shaded bars 
corresponding to characteristics of associated requests. A black bar 5530 indicates a physical 
request (i.e. typically a mechanical operation), a bar having a first shading characteristic 5532 
indicates a programmable request (i.e. typically a request to a robot), a bar having a second 
shading characteristic 5534 indicates a virtual request (i.e. a request which is performed by an 
entity which is not controlled by the control system such as a human operator) and a bar 
having a third shading characteristic 5536 indicating a conditional (i.e. a characteristic which 
must be met prior to other requests occurring thereafter.) 

[00342] Referring now to Fig. 59, to begin specifying CAS for controlling the 

mechanical resources in timing diagram 5820, a control engineer selects an add icon 5542 
from tool bar 5502 which opens a pull down window with a single option 5544 entitled 
"control assembly." Referring to Fig. 60, when option 5544 is selected, a window menu 5546 
opens up which includes a control assembly type list 5548, a "new" icon 5550 and a "cancel" 
icon 5552. The CA types in list 5548 include each of the CAS in list 5512 including "safe 
bulk head clamp set type" 5554. The engineer may select any CA type from list 5548. In the 
present example, it is assumed that, initially, the engineer wishes to select a CA for 
controlling four clamps which move simultaneously during the mechanical procedure 
specified by timing diagram 5830. To this end, the engineer selects the "safe bulk head 
clamp set" type 5554 and thereafter selects the new icon 5550 indicating that a new CA 
instance is being specified. 

[00343] When the "safe bulk head clamp set" type 5554 is selected, although not 

illustrated and observable by a system user, resource editor 9802 automatically identifies 
every mechanical resource within mechanical resource window 5504 which could possible be 
controlled via an instance of the "safe bulk head clamp set" CA and stores the list of 
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mechanical resources in ECDB 9810 ( see Fig. 90). The controllable mechanical resource list 
is subsequently provided to the system user to help the system user identify mechanical 
resources to be controlled by the specific CA instance as will be explained in more detail 
below with respect to Figs. 64 and 65. 

[00344] Referring to Fig. 61, when new icon 5550 is selected, an instructions window 

5556 opens which helps guide the engineer through use of resource editor 9802. To this end, 
window 5556 indicates that a name must be specified for the specific CA instance being 
created or instantiated, the resources that will be controlled by the CA must be specified and, 
for control devices in the C A which have a variable number, the number of control devices to 
be included in the CA must be specified. 

[00345] When a "next" icon 5558 is selected, referring to Fig. 62, a window 5562 

opens up which includes a name field 5564 for specifying a name for the specific instance of 
the "safe bulk head clamp set" CA being instantiated. The engineer specifies the name in 
window 5564. In addition, window 5562 includes a plurality of different options and 
corresponding flag boxes for selecting those options for the CA. The options include 
specifying an HMI for the assembly 5566, specifying simulation tools for the assembly 5568, 
creating a wiring diagram for the assembly 5570, creating diagnostics for the assembly 5572 
and creating documentation for the assembly 5574. 

[00346] Flag boxes corresponding to the options 5560 through 5574 are identified 

generally by numeral 5576. When a flag appears in one of flag boxes 5576, the function 
associated therewith is requested. Initially it is assumed that each of flag boxes 5576 includes 
a flag so that, initially, each of the options 5560 through 5574 is initially selected. 
[00347] To deselect one of the functions, the mouse controlled cursor is positioned 

within a particular flag box 5576 and a mouse selection button is activated at which point the 
flag is removed from the box. Once the flags in boxes 5576 have been set as desired and a 
name has been provided in box 5564, "next" icon 5558 is again selected. 
[00348] As illustrated in Fig. 63, in the present example, the CA instance name 5578 

provided in box 5564 is "lstclamps". When "next" icon 5558 is selected, referring to 64, 
another window 5580 is provided which includes a mechanical resource list window 5582 
and a selected resource list window 5584 along with "add" and "delete" icons 5586 and 5588, 
respectively. 

[00349] As indicated above with respect to Fig. 60, when the 

"SafeBulkHeadClampSet" CA type was selected ( see Fig. 60), resource editor 9802 
automatically accessed the mechanical resource list in window 5504 and identified each 
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mechanical resource in window 5504 which could possibly be controlled via the selected CA 
type. For example, in the present case, because the "SafeBulkHeadClampSet" CA type 5554 
was selected, editor 9802 searched the resource list in window 5504 and identified every 
clamp within window 5504 to form a list of possible mechanical resources to be controlled by 
the particular instance of the "safe bulk head clamps set" CA. The list of clamps controllable 
by the first clamps control assembly is provided in mechanical resource list window 5582. 
Initially, selected resource list 5584 is blank. 

[00350] To select clamps from the list in window 5582 to be added to the selected 

resource list window 5584, an engineer uses a mouse controlled cursor to highlight one or 
more of the clamps in list 5582 and then selects "add" icon 5586. In the present example it is 
assumed that a CA is only capable of controlling a maximum of four clamps at one time. 
Thus, referring to Fig. 65, after four clamps 5590, 5592, 5594 and 5596 have been added to 
list window 5584, no more clamps can be added. To remove a clamp from window 5584 and 
hence deselect the clamp, the clamp is highlighted in window 5584 and the "delete" icon 5588 
is selected. 

[00351] Referring now to Figs. 65 and 85, each time a clamp is added to list 5584, a 

flag is provided in another one of flag boxes 9482a, 9484a or 9486a to select an additional set 
of cylindicator logic for instantiation in the CA logic specification 9002. In addition, a clamp 
indicator name indicating a specific clamp associated with the cylindicator logic is provided. 
For example, 1st cylindicator 9425 is labeled "clamp 2506A", 2nd cylindicator 9427 is 
labeled "clamp 4502" and so on. Therefore, at the end of adding each of clamps 5590, 5592, 
5594 and 5596 to list 5584, four distinct sets of cylindicator logic corresponding to 
cylindicators 9425, 9427, 9429 and 9431 are instantiated in logic specification 9002. 
[00352] Referring to Figs. 85 and 85 A, when a flag is provided in one of boxes 9482a, 

9484a or 9486a, a flag is also provided in a corresponding selection box 9482f, 9484f and 
9486f, respectively. Flags in boxes 9482f, 9484f and 9486f indicate that corresponding 
cylindicators 9427, 9429 and 9431, respectively, will be represented in a compiled schematic. 
[00353] In addition, referring to Figs. 65, 85 and 86, each time a clamp is added to list 

5584 so that a flag is provided in one of boxes 9482a, 9484a or 9486a, a flag is also provided 
in a corresponding flag box 9482b, 9484b or 9486b, respectively. These flags indicate that 
additional monitorable I/O and controllable outputs/requests corresponding to the second 
through fourth cylindicators 9427, 9429 and 9431, respectively, should be designated for 
presentation during subsequent HMI feature selection using the HMI editor 9804 described 
below. 
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[00354] Moreover, referring to Figs. 65, 85 and 87, each time a flag is provided in one 

of boxes 9482a, 9484a or 9486a, a flag is provided in a flag box 9482c, 9484c or 9486c 
corresponding to an associated cylindicator listed in column 9602. The flags in column 9602 
indicate that additional diagnostics corresponding to each of the flag cylindicators is 
designated for presentation during subsequent diagnostics feature selection using the 
diagnosis editor 9806 described below. 

[00355] Furthermore, referring to Figs. 65 and 88, each time a clamp is added to list 

5584 so that a flag is provided in one of boxes 9482a, 9484a or 9486a, corresponding flags 
are provided in flag boxes in simulation specification 9300. For example, if a flag is placed 
in box 9482a corresponding to second cylindicator 9427, corresponding flags are placed in 
boxes 9482d and 9482e which likewise correspond to second cylindicator 9427. Flags in 
boxes 9482d and 9482e indicate instantiation of the information in tables 9303 and 9305 for 
subsequent compilation. 

[00356] In addition, when a table in specification 9300 is instantiated, the name 

mechanical resource to be controlled by a cylindicator corresponding to the table is added to 
the table. For example, resource name "clamp 2506A" is added to tables 9302 and 9304 
corresponding to 1st cylindicator 9425 which will control clamp 2506A, resource name 
"clamp 4502" is added to tables 9303 and 9305 corresponding to 2nd cylindicator 9427 which 
will control clamp 4502. Similarly, resource names corresponding to clamps 5508B and 
5 5 09 A are provided for 3rd and 4th cylindicator tables like tables 9302 and 9304. 
[00357] Referring to Figs. 65 and 66, after clamps 5590, 5592, 5594 and 5596 have 

been added to list 5584, the control engineer may select "next" icon 5558 which opens a 
Istclamps summary window 5607. Summary window 5607 includes a summary table 5609 
including a label column 561 1, a control component column 5613, a type column 5615 and a 
function column 5617. Label column 561 1 lists each of the mechanical resources which are 
to be controlled by the "Istclamps" CA and therefore includes clamps 5590, 5592, 5594 and 
5596. 

[00358] Control component column 5613 lists all of the control components or control 

mechanisms which are controlled by the "Istclamps" CA and correlates control components 
with mechanical resources in column 561 1. To this end, a separate air cylinder is correlated 
with each of clamps 5590, 5592, 5594 and 5596. In addition, air valves 5619 and 5621 
corresponding to the two position valve 9421 and the spring return valve 9423 ( see Fig. 85) 
are also provided in column 5613. 



-60- 



[00359] Type column 5615 lists control mechanism types corresponding to each of the 

control components in column 5613 and, to this end, lists a double solenoid corresponding to 
air valve 5619, a single solenoid corresponding to air valve 5621 and separate cylindicators 
corresponding to each of the air cylinders in column 5613. 

[00360] Function column 5617 lists the function of each of the control components in 

column 5613. To this end, column 5617 indicates that air valve 5619 provides main control 
for the "lstclamps" CA, that air valve 5621 is a safety valve and that each of the air cylinders 
in column 5613 is provided as an air-motion converter. Thus, table 5609 simply summarizes 
the various control components, their types and functions which have already been specified 
with respect to the "lstclamps" CA. 

[00361] To further parameterize the "lstclamps" CA, the control engineer may select 

"edit" icon 5623. Referring to Figs. 66 and 85, when "edit" icon 5623 is selected, an editing 
window 5625 is opened which enables the control engineer to further parameterize the 
"lstclamps" CA. To this end, window 5625 essentially displays all of the logic in the 
"lstclamps" CA logic specification 9002 including each of the control devices (i.e. two 
position valve 9421, spring return valve 9423, and first through fourth cylindicators 9425, 
9427, 9429 and 9431), each of their inputs and outputs, the extend logic and retract logic 
charts and properties sections 9036 and 9066. Various types of parameterization can be 

performed using window 5625 and a mouse controlled cursor. To this end, using the mouse 
controlled cursor, an engineer can modify any of the latch, restart, or inverse request 
properties in properties sections 9036 and 9066 by either placing flags in flag boxes 9051, 
9053, etc., or removing flags from those boxes. In addition, the control engineer can select or 
deselect any of the spring return valve 9423, cylindicator 9427, cylindicator 9429, or 
cylindicator 9431 by placing flags in or removing flags from boxes 9480a, 9482a, 9484a or 
9486a, respectively. As indicated above, flag manipulation in boxes 9480a, 9482a, 9484a 
and 9486a ripples through other CA specifications ( see Figs. 85A, 86, 87 and 88). Referring 
still to Fig. 85, after properties within sections 9036 and 9066 have been set as desired and 
the control devices have been selected as desired, the control engineer may select the "back" 
icon 5631 to return to summary window 5607 illustrated in Fig. 66. Although not illustrated, 
when the engineer returns to window 5607, if the spring return valve 9423 has been 
deselected, air cylinder 5621 and other information within table 5609 corresponding thereto 
will not appear within table 5609 or, may appear in a form which is recognizable as a form 
indicating a deselected control component and corresponding information (i.e. air valve 5621 
and information corresponding thereto may be highlighted in some manner). Hereinafter it 
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will be assumed that the control engineer does not de-select valve 9423 and therefore valve 
9423 remains instantiated in the lstclamps CA instance. Referring to Fig. 66, to continue, 
the control engineer selects "next" icon 5558 which opens a completed assembly summary 
window 5633 illustrated in Fig. 67. Window 5633 specifies the new control assembly type as 
a "SafeBulkHeadClampSet" 5635 type, the instance of which is named "lstclamps" 5637. In 
addition, window 5633 also provides information about the CA instance author, the date of 
instantiation, and other useful information corresponding to the "lstclamps" CA. 
[00362] Referring to Figs. 67 and 92, after confirming the correctness of all of the 

information in window 5633, the control engineer selects "next" icon 5558 which opens a 
sequencing window 5651. Window 5651 provides instructions to the engineer indicating that 
the engineer may either manually sequence lstclamps CA instance requests or, in the 
alternative, may allow the resource editor 9802 to automatically sequence the lstclamps 
requests. To this end, editor 9802 provides an icon for each possible lstclamps CA request 
and an "automatic" icon 5657. Referring again to Fig. 85, because the lstclamps CA only 
includes extend and retract requests 9031, 9033, respectively, editor 9802 provides an 
"extend" icon 5653 and a "retract" icon 5655 within window 5651. 

[00363] To manually place the " 1 stclamps" "extend" request within the control bar 

chart in window 5510, the control engineer selects "extend" icon 5653. Referring also to Fig. 
59, after selecting "extend" icon 5653, the control engineer uses a mouse controlled cursor to 
select either a space or an edge within bar chart 5830 for placement of the extend request. In 
Fig. 59, exemplary edges are identified by numerals 5529 and 5527 which define an empty 
space 5531 therebetween. In the present example, it will be assumed that the engineer selects 
space 5531 by placing the cursor therein and activating a mouse selection button. When 
space 5531 is selected, referring also to Fig. 69, editor 9802 places a black bar within space 
5531, identifies lstclamps in control assembly column 5522 and identifies extend request 
7001 in the request column 5524. A similar manual operation can be performed to place the 
lstclamps retract request in bar chart 5830, a black bar corresponding thereto placed in space 
5671 is illustrated in Fig. 70. In the alternative, referring again to Figs. 90 and 92, by 

selecting "automatic" icon 5657, the control engineer causes resource editor 9802 to 
automatically sequence both the lstclamps "extend" and "retract" requests. To this end, when 
"automatic" icon 5657 is selected, referring also to Fig. 70, editor 9802 automatically 
sequences the lstclamps "extend" request with the period in mechanical timing diagram 5820 
corresponding to extension of the clamps 5590, 5592, 5594 and 5596 in the lstclamps CA. 
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To this end, the clamp extension period is identified in mechanical timing diagram 5820 as 
period 5673. Therefore, because space 5531 corresponds to period 5673, editor 9802 
automatically places a bar within space 5531, identifies lstclamps in column 5522 and 
identifies "extend" request in column 5524. Similarly, editor 9802 automatically places the 
lstclamps retract request in space 5671 corresponding to the period 5675 during which the 
clamps 5590, 5592, 5594 and 5596 associated with the lstclamps CA retract. 
[00364] Initially, it may appear as though manual sequencing of requests is not 

necessary and that an engineer should always allow resource editor 9802 to automatically 
sequence CA requests. While this may be true for simple devices such as a clamp or a pin 
locator, many other mechanical resources are much more complex and may perform separate 
requests during a complete manufacturing process, some of which are not reflected in the 
mechanical timing diagram 5820. For example, in the case of an exemplary robot, many 
robots are programmed to perform housekeeping requests at the beginning of each new 
manufacturing cycle (a manufacturing cycle corresponding to a single pass through 
mechanical timing diagram 5820). In this case, while the exemplary robot may perform a 
single "forward" request during a fifth mechanical timing diagram period and may perform a 
"reverse" request during a twelfth mechanical timing diagram period, it may be necessary for 
the robot to perform housekeeping functions/requests prior to the first period in the 
mechanical timing diagram 5820. In the alternative, it may be necessary for the robot to 
perform the housekeeping requests at some other time (e.g. between the third and fourth 
diagram periods) or more than once during a manufacturing cycle. In this case, the robot 
requests to be sequenced would include a housekeeping request, a "forward" request and a 
"reverse" request. While resource editor 9802 may be able to automatically, place the forward 
and reverse requests as a function of the sequencing of similar activities in mechanical timing 
diagram 5820, editor 9802 would have no way of determining where to sequence the 
housekeeping request. Although not described here in detail other circumstances requiring 
manual placement of requests do occur. 

[00365] Referring once again to Fig. 69, after the lstclamps "extend" and "retract" 

requests have been placed within diagram 5830, the "lstclamps" CA instance of the 
"SafeBulkHeadClampSet" template type is identified within control resources window 5508 
as" lstclamps" 6910 in a hierarchal fashion and the "extend" and "retract" requests are placed 
under lstclamps 6910 as requests 691 1 and 6913, respectively. 
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[00366] Referring now to Fig. 71, after the lstclamps "extend" and "retract" requests 

have been sequenced within diagram 5830, the control engineer again access window 5546 to 
select another control assembly type from list 5548 for controlling additional mechanical 
resources in diagram 5820. The process described above is repeated until CA instances have 
been instantiated (i.e. specified, parameterized and sequenced) for every mechanical resource 
in diagram 5820. An exemplary completed control bar chart 5830 is illustrated in Fig. 72. 
[00367] Referring to Figs. 72 and 92, after CA sequencing the control engineer again 

selects "next" icon 5558 which, as illustrated in Fig. 93, opens up a contingencies window 
5681. Window 5681 includes a list 5683 of contingencies 5685, 5687, ... 5689 upon which a 
request may be made contingent. Generally, resource editor 9802 generates contingency list 
5683 by gleaning the "done" I/O combinations corresponding to every CA request for every 
CA included in list 5522 ( see Fig. 72). For example, referring also to Fig. 85, the done 
condition 5691 corresponding to the lstclamps extend request 9031 requires active solenoid 
outputs Ol, 02, OS and 06, passive solenoid outputs 03 and 04, active proximity sensor 
inputs II, 13, 15 and 17 and passive proximity sensor inputs 12, 14, 16 and 18. Other 
contingencies, in addition to done I/O combinations may also be specified within list 5683. 
For example, referring again to Fig. 85, another exemplary contingency may simply require 
that outputs Ol and 02 be active and may be independent of the condition of other outputs 
and cylindicator inputs in the lstclamps CA instance which contingencies are provided in list 
5683 is a matter of CA designer choice. 

[00368] Referring to Figs. 93 and 94 after a contingency from list 5683 has been 

selected, a second contingencies window 5695 opens. In the present example, it is assumed 
that the second contingency 5687 has been selected from list 5683 and therefore, the second 
contingency 5687 is indicated in window 5695. In addition, editor 9802 provides an 
"interlock" icon 5697 and a "safety" icon 5699 adjacent contingency 5687 in window 5695. 
[00369] On one hand an interlock is a contingency which must be met and must exist 

at the beginning of a request subject thereto but need not continue to exist during 
performance of the request. For example, an interlock may require that a clamp be parked in 
a retracted position prior to a transfer bar moving a work piece adjacent thereto. After the 
transfer bar begins to move, continued transfer bar movement does not required that the 
clamp remain parked. On the other hand a safety is a contingency which must exist at the 
beginning of, and must continue to exist during the course of, a request which is subject 
thereto. For example, if a parked clamp is a safety linked to transfer bar movement, as a 
transfer bar moves, if the clamp is moved, the transfer bar is immediately stopped. 
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[00370] Referring again to Fig. 93, any of the contingencies in list 5683 may be 

labeled as either an interlock or a safety. Referring also to Figs. 94 and 72, assuming 
"interlock" icon 5697 is selected, editor 9802 provides bar chart 5830 as illustrated and allows 
the control engineer to select any edge (e.g. 5529, 5527, etc.) by placing a mouse controlled 
cursor on the edge and activating a mouse selection button. For example if the second 
contingency corresponds to a parked transfer bar and the control engineer wishes to make the 
lstclamps "extend" request 5701 contingent upon the transfer bar being parked, the control 
engineer may select edge 5529. 

[00371] Referring still to Fig. 72, when an edge is selected for placement of an 

interlock or a safety, preferably some contingency indication is added to control bar chart 
5830. To this end, in the present example, a "yield" icon 5703 is provided at the top of bar 
chart 5830 which is linked to the selected edge 5529. It is contemplated that, if icon 5703 is 
selected by an engineer, editor 9802 will open another window (not illustrated) which will 
specify the nature of the interlock associated with the corresponding edge. 
[00372] Referring to Figs. 72 and 94, by selecting "safety" icon 5699, a procedure 

similar to the procedure described above for selecting an edge for an interlock is used to 
select an edge for the safety. In Fig. 72 it is assumed that edge 5705 is selected for the safety. 
In this case, instead of providing a "yield" icon 5703, where a safety is associated with an 
edge, a "stop" icon 5707 is provided which is linked to the selected edge (see 5705). Once 
again, if an engineer selects icon 5707, editor 9802 opens a window (not illustrated) which 
specifies the nature of the safety associated with the corresponding edge. 
[00373] Referring still to Fig. 72, while only a single interlock contingency 5703 and a 

single safety contingency 5707 are illustrated, many different contingencies may be added to 
bar chart 5830. In addition, it is contemplated that more than a single interlock or safety or, 
indeed, both interlocks and safeties may be linked to a single edge. Where both interlocks 
and safeties are linked to a single edge, editor 9802 provides both a "yield" icon and a "stop" 
icon above the corresponding edge. In addition, is should be appreciated that other way to 
indicate interlocks and safeties and specifying interlocks and safeties are contemplated by the 
present invention and that the present invention should not be limited by the description 
included herewith. For example, another way to indicate interlocks and safeties may be to 
provide a comment directly on bar chart 5830 which comprises text in a conditional 
horizontal space where the edge occurs. 
[00374] b. HMI Editor 

In addition to the logic and sequencing described above in the context of resource 
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editor 9802, it is also necessary to specify features of each sequenced CA which are to be 
monitored and controlled via an HML For example, referring again to Fig. 86, with respect 
to the lstclamps CA described above, while virtually all lstclamps I/O may possibly be 
monitored and all lstclamps outputs and extend and retract requests 9031, 9033 maybe 
controllable, it is unlikely that a control engineer or a system operator would require or desire 
such extensive monitoring and control capabilities. Instead, in the context of the lstclamps 
example, it is more likely that a system operator would only require or desire a sub-set of the 
I/O to be monitored and would only require a sub-set of the outputs and possible requests to 
be controllable. In the present example it will be assumed that the operator only requires 
controls for separately controlling the "extend" and "retract" requests and monitorable 
indicators to indicate the active/passive status of the first cylindicator 9425 inputs II and 12. 
[00375] To this end, referring to Fig. 95, an exemplary HMI screen 7003 suitable for 

controlling and monitoring the lstclamps CA in the manner indicated above is illustrated. 
Screen 7003 is divided into an HMI section 7005 and a diagnostic section 7007. HMI 
section, 7005 is divided into separate control sections 7009, 7011, 7013 and 7015. 
Diagnostic section 7007 is described in more detail below. 

[00376] Referring also to Fig. 72, it is contemplated that HMI section 7005 may 

potentially include a separate controls section for each control assembly listed in control 
assembly column 5522. In the alternative, a control system may include a plurality of 
controls screens, a separate screen for controlling and monitoring each control assembly in 
column 5522 or to separate screens for controlling distinct sub-sets of the control assemblies 
is column 5522. In Fig. 95, only four control sections 7009, 701 1, 7013 and 7015 are 
illustrated, the control sections 7009, 701 1, 7013 and 7015 corresponding to the above 
described lstclamps CA and 2nd, 3rd and 4th clamps CAS, respectively. Only control 
section 7009 is shown with some detail, sections 701 1, 7013 and 7015 abbreviated to 
simplify the present explanation. Nevertheless, it should be understood that each of sections 
7011, 7013 and 7015 and additional control sections (not illustrated) corresponding to other 
CA instances would include control tools and monitoring indicators of various types and 
configurations. 

[00377] Referring still to Fig. 95, exemplary control section 7009 includes an 

indication 7017 of the CA instance (i.e. lstclamps) which is controllable and monitorable via 
section 7009 and also includes control tools and monitoring indicators corresponding to the 
lstclamps CA. To this end, the exemplary control section 7009 includes a virtual "extend" 
button icon 7019 and a virtual "retract" button icon 7021. It is contemplated that a mouse 



-66- 



controlled cursor (not illustrated) can be used by a system operator to select either of icons 
7019 or 7021 to cause the control mechanisms associated with the Istclamps CA to force 
corresponding clamps into the extended and retracted positions, respectively. In the 
alternative, where a system is equipped with touch screen HMI's, each of icons 7014 and 
7021 is selectable via touch. 

[00378] In addition to icons 7019 and 7021, control section 7009 also provides a 

representation of each Istclamps control device for which I/O is to be monitored. In the 
present example, referring again to Fig. 86 and also to Fig. 95, because it has been assumed 
that inputs II and 12 corresponding to the first cylindicator 9425 are to be monitored, the first 
cylindicator 9425 is identified in section 7009. Moreover, monitoring indicators, 7023 and 
7025 are provided for first cylindicator 9425. Indicators 7023 and 7025 indicate extended 
and retracted first cylindicator conditions. Thus, extended and retracted 1st cylindicator 
labels are provided adjacent indicators 7023 and 7025, respectively. 

[00379] It should be appreciated that while one configuration for an HMI is described 

above and with respect to Fig. 95, other HMI configurations are contemplated by the present 
invention and the invention should not be limited by the described configuration. To this 
end, it is contemplated that each CA is simply used to indicate I/O to be monitored and 
controlled and that the compiler 9812 ( see Fig. 90) includes rules for specifying HMI 
configuration based on CA specified I/O which must be supported by an HMI. 
[00380] In addition, referring again to Fig. 90 while the HMI editor 9804 could be 

entirely separate from resource editor 9802 and could be used after sequenced CAS have 
been compiled, in the present example, HMI editor 9804 will be described as an editor which 
can be used in a seamless manner to move from using resource editor 9802 to HMI tools for 
specifying I/O to be monitored and controlled. To this end, referring once again to Fig. 94, 
after all interlocks and safeties have been specified for sequenced CAS, the control engineer 
selects "next" icon 5558 once again. When icon 5558 is again selected, referring to Fig. 96, 
resource editor 9802 provides a window 7027 enabling the engineer to specify either HMI or 
diagnostics information. Window 7027 includes an "HMI" icon 7029 and a "diagnostics" 
icon 7031. By selecting "diagnostics" icon 7031 the engineer enters the diagnostics editor 
9806 described in more detail below. 

[00381] Referring to Figs. 96 and 97, when "HMI" icon 7029 is selected, control is 

shifted to HMI editor 9804 which provides a first HMI editor screen 7033. Referring also to 
Fig. 72, list 7035 includes all of the CA instances grouped by CA type which appear in 
control resources window 5508. Thus, the Istclamps CA instance 7037 appears along with 
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the 2nd clamps, 3rd clamps and 4th clamps instances under the CA type 
"SafeBulkHeadClampSet" 7039 in list 7035. Once again a mouse controlled cursor (not 
illustrated) is used by the control engineer to select one of the CA instances at a time for 
identifying I/O to be monitored and controlled via an HMI to be subsequently configured by 
compiler 9812 (see Fig. 90). 

[00382] Referring to Figs. 97 and 98, when the control engineer selects the Istclamps 

instance 7037, editor 9804 provides a second HMI screen 7041. Referring also to Fig. 86, it 
should be appreciated that the information provided on screen 7041 is similar to the 
information stored in HMI table 9460 including a device column 7043, a monitorable I/O 
column 7045 and a controllable outputs/requests column 7047. 
[00383] While the information provided on screen 7041 appears similar to the 

information in table 9460, there are a number of important distinctions. First, referring to 
Figs. 86 and 95, the information provided on screen 7041 reflects only required and selected 
control devices and corresponding monitorable and controllable I/O from table 9460. In the 
present example, both two position valve 9421 and cylindicators 9425 are required and 
therefore appear on screen 7041. Spring return valve 9423 has remained selected and each of 
the second through fourth cylindicators 9427, 9429 and 9431 have been selected and 
therefore each of those devices also appear in table 7041 . However, if spring return valve 
9423 had been de-selected (i.e. via box 9480a in Fig. 85), spring return valve 9423 and 
corresponding monitorable and controllable I/O would not appear on screen 7041. Similarly, 
if one or more of the second, third or fourth cylindicators 9427, 9429 or 943 1 had not been 
selected (i.e. via boxes 9482a, 9484a and 9486a in Fig. 85), the cylindicator(s) not selected 
and corresponding monitorable and controllable would not appear on screen 7041. 
[00384] Second, at this point it is contemplated that the control devices for the 

Istclamps CA instance have already been selected using resource editor 9802 and therefore, 
cannot be selected or de-selected using the HMI editor 9804. Therefore, while flag boxes 
9480b, 9482b, 9484b and 9486b appear in table 9460, none of those boxes appear adjacent 
device representations in column 7043. 

[00385] Referring still to Fig. 98, initially flag boxes (e.g. 7049, 7051, etc.) 

corresponding to monitorable and controllable I/O and requests in columns 7045 and 7047 
are blank (i.e. do not include flags). It is contemplated that any of the flag boxes may be 
selected via a mouse controlled cursor by selecting the box and activating an activation 
button on the mouse. In the present example, it is assumed that the control engineer would 
like to provide control tools for controlling each of the extend and retract requests and would 
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like to provide monitorably indicators for each of the first cylindicator 9425 inputs II and 12 
(e.g. see exemplary HMI screen in Fig. 95.) To specify monitorably and controllable I/O, the 
control engineer uses the mouse controlled cursor to place flags in boxes 7053 and 7055 
corresponding to inputs II and 12, respectively, and to place flags in boxes 7057 and 7059 
corresponding to extend and retract requests, respectively. These flags are illustrated in Fig. 
98. To specify other I/O to be monitored/controlled the engineer places additional flags in 
boxes. To de-select a selected I/O, the engineer simply re-selects the corresponding box to 
remove the flag. 

[00386] Referring to Figs. 86 and 98, when flags are placed in boxes 7053, 7055, 7057 

and 7059, editor 9804 provides corresponding flags in boxes 9493, 9495, 9490 and 9492, 
respectively. Thus, HMI editor 9804, including screens 7033 ( see Fig. 97) and 7041 ( see Fig. 
98), is used to select a sub-set of the monitorable and controllable I/O and requests 
corresponding to designated control devices. The selected I/O and requests are indicated in 
table 9460 and later used during compilation to provide execution code to support the HMI 
and to generate a HMI program to support the HMI tools/indicators, etc. 
[00387] In addition, when a flag is placed in any of the boxes in column 7047 

indicating manual control, a flag is automatically placed in a manual selection box 9051 
indicating that a control tool for selecting manual system operation must be provided on a 
final HMI. 

[00388] When the control engineer is finished setting the flags on screen 7041 

corresponding to the lstclamps CA instance, the engineer selects the "finish" icon 7061 which 
again brings up the HMI editor screen 7033 ( see Fig. 97). Next, the engineer may select any 
of the other CA instances in list 7035 for selecting monitorable and controllable I/O in the 
manner described above. When another CA instance is selected from list 7035, another HMI 
editor screen similar to screen 7041 ( see Fig. 98) is displayed which includes monitorable and 
controllable I/O specified by the CA instance and which can be selected via flags to be 
supported by a subsequently compiled execution code. 

[00389] Referring to Figs. 96 and 97, after the control engineer has set all of the flags 

corresponding to monitorable and controllable I/O which have to be supported by an HMI 
and corresponding execution code, the engineer selects "finish" icon 7061 to return to 
window 7027. At this point, HMI specification is complete. 
[00390] c. Diagnostics Editor 

Referring again to Fig. 87, while diagnostic specification tables like table 9600 
designate a large number of diagnostic conditions and associated activities for CAS 
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sequenced via resource editor 9802, as in the case of the HMI specification ( see Fig. 86), 
often a control engineer will only require a sub-set of possible diagnostic capabilities. Thus, 
referring to Figs. 87 and 90, diagnostics editor 9806 provides tools which enable a control 
engineer to select a sub-set of the requirement/activity possibilities in table 9600 to be 
supported by a subsequently compiled execution code. Referring also to Fig. 95, in the 
present example, while the execution code is running, when a diagnostic condition to be 
reported occurs, the condition is reported in diagnostics section 7007 as a text phrase. 
[00391] Referring to Figs. 96 and 99, a control engineer selects "diagnostics" icon 

703 1 to specify diagnostics to be supported by the execution code. When icon 703 1 is 
selected, diagnostics editor 9806 provides diagnostics editor screen 7101. Screen 7101, like 
HMI editor screen 7033 illustrated in Fig. 97, provides a control assembly instances list 7103 
which, referring once again to Fig. 72, lists each control assembly instance, according to 
control assembly type, from control resources window 5508. Thus, once again, the "first 
clamps" CA 7105 is listed as an instance of the "safe bulkhead clamp set" control assembly 
type 7107 in list 7103. 

[00392] Referring still to Fig. 99, using a mouse controlled-cursor (not illustrated), the 

control engineer selects each of the CA instances from list 7103 one at a time for which 
diagnostics is to specified. Continuing with the present example, referring also to Fig. 100, it 
is assumed that the engineer selects the "first clamps" CA 7105 at which point diagnostics 
editor 9806 provides diagnostics editor window 7109. 

[00393] Referring to Figs. 87 and 100, window 7109 provides essentially all of the 

information from diagnostic specification table 9600 and therefore includes a device/requests 
column 71 1 1, a requirements column 7113, and an activities column 7115. Each device in 
the "Istclamps" CA instance for which diagnostic specification is provided in diagnostics 
table 9600 is listed in device/requests column 7111. Requirements corresponding to each 
device in column 7111 are listed in column 7113 and corresponding activities to be 
performed if the requirement in column 71 13 is met are listed in column 7115. In addition, 
selection boxes 7117, 7119, 7121, 7123, 7125, and 7127 are provided adjacent each 
requirement representation in column 7113. Initially, in the present example, it is assumed 
that each of boxes 7117 through 7127 is blank indicating that diagnostics to be supported by 
execution code are not initially selected. However, using a mouse-controlled cursor, a flag 
may be placed in any of boxes 7117 through 7127, in a sub-set of those boxes, or in each of 
those boxes, indicating that the diagnostics corresponding to the specific device or request 
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and corresponding requirements and activities should be supported. In Fig. 100, exemplary 
flags are illustrated in boxes 7117, 7125, and 7127. 

[00394] Referring still to Figs. 87 and 100, when a flag is placed in any of boxes 7117 

through 7125, diagnostics editor 9806 places a corresponding flag in a diagnostic 
specification table box 2001, 2002, 2003, etc. Thus, diagnostics editor 9806 including 
screens 7101 (see Fig. 99) and 7109 ( see Fig. 100) which are used to further specify or select 
information in diagnostics table 9600 which is to be subsequently compiled. 
[00395] When the flags have been selected and deselected as desired on screen 7109, 

the engineer selects "finish" icon 7601 and editor 9806 again provides screen 7101 illustrated 
in Fig. 99. Next, the engineer selects another CA instance from list 7103 to select diagnostics 
to be supported and follows the flag selecting and deselecting procedure described above for 
the newly selected instance. This procedure is repeated for each CA instance for which 
diagnostics is to be supported by the execution code. Thereafter, referring still to Fig. 99, the 
engineer again selects "finish" icon 7601 and is returned to screen 7027 illustrated in Fig. 96. 
[00396] Referring again to Fig. 87A, in the alternative, where CAS include status 

based diagnostic specifications, it is contemplated that, in a preferred embodiment, the 
diagnostics specification is not edited. Instead, upon compiling, diagnostics specified in each 
diagnostics specification is repeated for each instantiated CA thereby generating diagnostics 
code which is interspersed within execution code and which indicates the next event to occur. 
In this manner, the daunting task of providing diagnostics code to support status based 
diagnostics is simplified through automatic code generation. 

[00397] At this point, all of the information required to generate execution code for 

controlling the exemplary manufacturing process and for supporting both HMI and 
diagnostics has been specified. In addition, all the information required to generate 
schematic diagrams detailing all aspects of a control assembly have also been specified. 
Moreover, all of the information required to support virtual simulation of the exemplary 
manufacturing process has been specified. Next, the sequenced bar chart and instantiated CA 
instances are stored in database 9810 until compiled. 

[00398] Hereinafter, although many bar charts and corresponding CA instances may be 

stored in database 9810, to simplify this explanation, it will be assumed that only single bar 
chart 5830 ( see in Fig. 72) and corresponding CA instances are stored in database 9810. 
[00399] 3. PLC and HMI 

Although it may seem logical to explain operation of compiler 9812 next, some 
general information about PLC 9814 and HMI 8437 is instructive in laying a foundation for 
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an understanding of how compiler 9812 operates. Specifically, it is instructive to understand 
the structure of the control products which must be generated via the compilation process to 
support execution code and an HML Generally the control products required to support code 
and an HMI include a parameterized PLC I/O table, an HMI configuration/linking table and 
a diagnostics linking table. 

[00400] Referring to Figs. 90 and 101, PLC 9814 includes a controller 2001 and at 

least one I/O card 2003. Controller 2001 includes a microprocessor 2005 and a memory 
2007. Memory 2007 is used to store both an execution code 2009 and a PLC I/O table 201 1 . 
Code 2009 includes an RLL control program for controlling mechanical resources 8438. As 
well known in the controls art, an RLL program includes sequential LL rungs including 
contacts and coils. The contacts represent PLC inputs and the coils represent PLC outputs. 
When contacts within a rung all close, an associated rung coil is excited. Thus, PLC inputs 
(contacts) change the states of PLC outputs (coils). PLC inputs are associated with 
mechanical resource sensors and indicate resource conditions. PLC outputs are linked to 
mechanical resource activators or to PLC input contacts to cause resource control or further 
processing. 

[00401] I/O table 201 1 is a repository for PLC I/O and PLC signals generally. 

Referring also to Fig. 102, an exemplary parameterized I/O table 201 1 includes signal 
column 2015 and a status column 2017. Column 2015 lists all PLC signals. For example, for 
the lstclamps CA instance, the signal list includes inputs lstclamps 11-18 and outputs 
lstclamps 01-06. For brevity sake table 201 1 is abbreviated, lstclamps 01, 02 and 06 are 
identified by numerals 8037, 8039 and 8043, respectively, lstclamps II and 12 are identified 
by numerals 8049 and 8046, respectively. Column 2015 also includes entries "lstclamps 
extend request" 2137, "lstclamps safety override" 2729, "lstclamps safety 1" 2049, 
"lstclamps safety 2" 2051, "lstclamps interlock 1" 2077, "lstclamps interlock 2" 2079, 
"lstclamps extend sensor error" 8113, "lstclamps cylinder failure" 8048, "lstclamps extend 
done" 8727, "manual" 21 13, "lstclamps 01 control" 2133 and so on. Each signal in column 
2015 corresponds to contact and or a coil in execution code 2009. 
[00402] Status column 2017 includes a list of instantaneous statuses of signals in 

column 2015. Exemplary statuses include closed or active which is identified by a "1" and 
open or passive which is identified by a "0". The statuses active and passive correspond to 
coils while closed and open correspond to contacts. 

[00403] Referring still to Fig. 101, I/O card 2003 is linked to controller 2001 via a two- 

way bus 2021. Card 2003 includes a plurality of I/O pins P-l, P-2, etc. Referring also to Fig. 
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102, each input pin is linked to a mechanical resource sensor while each output pin is linked 
to a mechanical resource activator. I/O card 2003 takes parallel input from pins P-l, P-2, etc. 
and converts the input to serial input signals which are provided to processor 2005 to update 
I/O table 201 1. Similarly, card 2003 receives serial PLC output signals from table 201 1 and 
converts those output signals to serial outputs provided on output pins for controlling 
mechanical resources. To map I/O pins to code I/O, table 201 1 includes a pin number 
column 2019. Not all PLC signals in column 2015 includes a pin number as some signals are 
internal to PLC 9814. For example, "lstclamps extend request" 2137 is a condition which is 
internal to PLC 9814 and therefore, does not correspond to a pin number. 
[00404] HMI 8437 is linked to controller 2001 via a two-way serial bus 2023 for 

retrieving PLC I/O which is to be monitored and for providing command signals for manual 
PLC control. HMI 8437 includes screen 7005 and both an HMI configuration/linking table 
2027 and a diagnostics linking table 2751. 

[00405] Referring to Fig. 95, exemplary HMI touch screen 7005 includes extend 

button 7019, retract button 7021 and manual button 1001. In addition, screen 7005 includes 
both "1st cylindicator extend signal" and "1st cylindicators retract signal" indicators 7023 and 
7025, respectively. 

[00406] Hereinafter, while many different control tools and indicators are 

contemplated, in order to simplify this explanation it will be assumed that the exemplary 
HMI only supports a single type of binary button and a single type of binary indicator. 
[00407] Referring still to Figs. 95 and 101, to define and support HMI screen 7005, an 

HMI configuration table 2027 must include at least three types of information. First, for each 
tool to be included on screen 7005, the table must indicate tool type (e.g. indicator or button). 
Second, for each tool, the table must specify a corresponding label (e.g. extend, retract, "1st 
cylindicator extend signal", etc.). Third, for each tool, the table must specify a corresponding 
PLC signal to, in the case of an indicator, be monitored and, in the case of a control button, 
be controlled. 

[00408] To this end, referring also to Fig. 103, exemplary parameterized HMI table 

2027 includes a tool column 2029 and an I/O column 2031. Tool column 2029 includes three 
sub-columns including a CA instance column 2701, a label column 2703 and a type column 
2705. Referring also to Fig. 72, instance column 2701 lists all CA instances in bar chart 5830 
which require HMI indicators or control buttons, lstclamps instance 7017 appears in column 
2701. 
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[00409] Referring to Figs. 102 and 103, signal column 2031 lists all PLC signals from 

PLC I/O table column 2015 for each CA instance in column 2701 which must be either 
monitored or controlled. Referring also to Fig. 86, consistent with HMI specification 9460, 
"lstclamps 11", "lstclamps 12", "Manual", "lstclamps extend request control" and "lstclamps 
retract request control", 8046,8049, 2131, 2135 and 2136, respectively, are included in 
column 2031. 

[00410] Type column 2705 lists the tool type required to monitor or control PLC 

signals in column 2031. To this end, indicators are listed for PLC signals to be monitored 
while buttons are listed for signals to be controlled. For example, indicator 7023 is specified 
for "lstclamps II" signal 8046. Label column 2703 lists a label for each tool in column 2705. 
Label-type pairs are singularities which correspond to indicators and control buttons which 
appear on HMI screen 7005. For example, referring also to Fig. 95, indicator 7023 and its 
corresponding label in Fig. 103 corresponds to indicator 7023 in Fig. 95. Indicator 7025 and 
its corresponding label "1st cylindicators retract signal" correspond to indicator 7025. 
Similarly, button 1001 and label "Manual" correspond to button 1001, button 7019 and its 
label in Fig. 103 correspond to extend button 7019 and button 7021 and its label in Fig. 103 
correspond to retract button 7021. 

[0041 1] Referring again to Fig. 95, diagnostic section 7007 of screen 7005 provides 

text error messages to a system operator when a supported diagnostic condition occurs. To 
support diagnostics functions, a diagnostics table must include at least two types of 
information. First, for each supported diagnostic condition, the diagnostics table must 
identify a PLC signal which indicates occurrence of the diagnostic condition. Second, for 
each supported diagnostic condition, the table must specify the message to be provided. 
[00412] To this end, referring to Figs. 101 and 104 exemplary parameterized 

diagnostics linking table 2751 includes a "link" column 2753 and an activity column 2755. 
Referring also to Fig. 102, link column 2753 lists PLC signals from column 2015 which 
correspond to supported diagnostic conditions. In exemplary table 2751 in the interest of 
brevity, only two supported conditions are listed including lstclamps extend sensor error" 
8113 and "lstclamps cylinder failure" 8048. 

[00413] Column 2755 includes a text phrase to be provided in diagnostics section 7007 

of screen 7005 when a corresponding signal in column 2753 is active. Thus, when signals 
81 13 is active (as specified in table 1 10), the phrase 2759 to be provided in section 7007 is 
cylindicator sensor failure. When signal 8048 is active, the phrase 2761 is provided. 
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[00414] Thus, referring to Figs. 95 and 101 through 104, in addition to execution code 

2013, PLC I/O table 201 1 is required to link code 2009 to I/O card pin numbers and hence to 
mechanical resources, HMI configuration/linking table 2027 is required to configure HMI 
screen 95 and to link HMI buttons and indicators to PLC signals in table 201 1 and 
diagnostics linking table 2751 is required to link diagnostic signals from PLC I/O table 201 1 
to diagnostic activities reported on HMI screen section 7007. 
[00415] 4. Compiler 

Referring to Figs. 72, 90, 95, 102, 103, and 104, compiler 9812 accesses bar chart 
5830 and corresponding CA instances in database 9810 and uses information therein to 
generate control products including execution code 2009 to be run by PLC 9814 to drive 
control mechanisms in the manner required by bar chart 5830, and PLC I/O table 201 1 for 
mapping code I/O to I/O card 2003 pins, HMI configuration/linking table 2027 to define one 
or more HMIs including HMI indicators for monitoring and buttons for manually controlling 
control mechanisms in a manner consistent with the CA instances and to link indicators and 
buttons to PLC signals, a diagnostics linking table 2751 for linking diagnostic PLC signals to 
diagnostic activities and a schematic representation of the entire control system which is also 
consistent with the CA instances. In addition, in this embodiment, compiler 9812 also 
generates a simulation table for driving virtual simulator 9816. 

[00416] Compiler 9812 is linked to database 9810 via a two-way bus 8013 and is also 

linked to PLC 9814, simulator 9816, HMI workstation 8437 and printer 8436 via buses 8323, 
8442, 8434 and 8444, respectively. During compilation compiler 9812 also stores 
information on database 9810 and may store the final control products on database 9810 as 
well. 

[00417] Referring now to Fig. 105, compiler 9812 includes a bar chart deconvolver 

8002, a CA parser 8005, a code compiler 8007, an HMI compiler 8009, a schematic compiler 
801 1 and a simulation compiler 8010. All of the components illustrated in Fig. 101 are 
linked via two way bus 8013. 

[00418] Deconvolver 8002 performs two functions. First, referring also to Fig. 72, 

deconvolver 8002 accesses bar chart 5830 and uses chart 5830 to sequence compilation. To 
this end, deconvolver 8002 works sequentially through bar chart 5830, one request at a time, 
causing compilers 8007, 8009, 801 1 and 8010 to simultaneously compile information for 
each bar chart request in an orderly fashion. For example referring to bar chart 5830, 
deconvolver 8002 begins by causing information related to the "2ndpins engage" request 
5201 (i.e. the first request in chart 5830) to be processed and compiled by each of compilers 
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8007, 8009, 801 1 and 8010. Thereafter, deconvolver 8002 causes information related to the 
"Gripper controller Load-Cycle" request 5203 to be processed and compiled and so on. 
[00419] While compilers 8007, 8009, 801 1 and 8010 generally process information for 

a request simultaneously, in the exemplary embodiment a parameterized PLC I/O table 
generated by code compiler 8007 is provided to schematic compiler 801 1 and therefore, some 
intra-request information processing is sequential. Nevertheless, in the present example all 
compilation for one request is completed prior to initiating compilation corresponding to a 
subsequent request. 

[00420] To cause compilation, deconvolver 8002 provides a "current request" signals 

to parser 8005 via bus 8013 indicating a single bar chart request at a time for which 
information is to be compiled. When parser 8005 receives a current request signal, parser 
8005 provides a sub-set of CA information for the current request to each compiler 8007, 
8009, 801 1 and 8010. Then, compilers 8007, 8009, 801 1 and 8010 process received 
information to generate control products. When each compiler 8007, 8009, 801 1 and 8010 
has completed its processing, the compiler sends a "request complete signal" to deconvolver 
8002 via bus 8013. When deconvolver 8002 receives a request complete signal from each 
compiler 8007, 8009, 801 1 and 8010, deconvolver 8002 provides the next request in bar chart 
5830 as a next current request signal to parser 8005. 

[00421] After information corresponding to the last request in bar chart 5830 has been 

processed, when deconvolver 8002 receives request complete signals from each of compilers 

8007, 8009, 801 1 and 8010, deconvolver 8002 provides an "end sequence signal" to each of 

compilers 8007, 8009, 8011 and 8010 indicating that the final compiling steps should be 

performed and final parameterized control products should be provided. 

[00422] Hereinafter, consistent with the present example, processing and compilation 

is described in the context of the "lstclamps extend" request 5701 in Fig. 72. 

[00423] Second, deconvolver 8002 also identifies safeties and interlocks from bar chart 

5830 and generates a safeties/interlocks (S/I) table which correlates CA instances with 

safeties and interlocks. The S/I table is provided to compiler 8007 via bus 8013. Although 

not illustrated, the S/I table is described in more detail below. 

[00424] Referring still to Figs. 72 and 105, in addition to receiving the current request 

signal, parser 8005 also accesses each CA instance corresponding to bar chart 5830 and 
parses the instances into their separate CA specifications. Thus, referring also to Fig. 84, 
parser 8005 separates each CA instance into a logic specification 9002, a schematic 
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specification 9004, an HMI specification 9006, a diagnostic specification 9008 and a 
simulation specification 9300. 

[00425] The specification sub-sets corresponding to each specific bar chart request are 

simultaneously provided to each compiler 8007, 8009, 801 1 and 8010. For example, when 
deconvolver 8002 indicates that the "lstclamps extend" request is to be processed, parser 
8005 provides specification sub-sets corresponding to the lstclamps extend request to each of 
compilers 8007, 8009, 8011 and 8010. 

[00426] The specification sub-set provided to compiler 8007 includes logic, HMI and 

diagnostic specifications 9002, 9006 and 9008, respectively. The specification sub-set 
provided to HMI compiler 8009 includes the HMI specification 9006 and diagnostic 
specification 9008. The sub-set provided to compiler 801 1 includes schematic specification 
8003. The sub-set provided to simulation compiler 8010 includes only the simulation 
specifications 9300. Each of the compilers 8007, 8009, 801 1 and 8010 is described 
separately below. 

[00427] In addition to storing bar chart 5830, CA type templates and instantiated CA 

instances corresponding to the stored bar chart, database 9810 also stores a plurality of 
database tables including information which compiler 9812 combines with CA instance 
information to generate the control products. The tables include a code building table ( see 
Fig. 106), an HMI building table ( see Fig. 1 10), a diagnostics building table ( see Fig. 1 1 1) a 
schematic building table (see Fig. 113) and a simulation building table ( see Fig. 115). 
Content and use of the building tables is described below. 

[00428] In the example which follows, while many different methods (e.g. building, 

duplicating, canceling, etc.) for parameterizing code, support tables, schematics and 
simulation tools are contemplated, only a single method which is particularly easy to 
visualize is described here in order to simplify this explanation. Generally, according to the 
method described herein, virtually all information which might be required to support a 
control product is defined and, upon compilation some of the defined information is 
eliminated. For example, with respect to execution code, code required to support every 
aspect, including both required and parameterizable aspects, of a CA request is provided and, 
upon compilation, code rungs which correspond to required and selected request 
characteristics remain in the code while rungs corresponding to un-selected request 
characteristics are effectively removed from the code. 
[00429] a. Code Compiler 

Referring to Figs. 72, 101 and 105, compiler 8007 receives logic, HMI and diagnostic 
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specifications and the S/I table for a specific CA instance, gleans information therefrom and 
applies a set of rules to the gleaned information to generate parameterized execution code 
segments and to form PLC I/O table sections for each bar chart 5830 request. Parameterized 
code segments are appended to each other in sequential order to form complete execution 
code 2009 for controlling the control process defined by bar chart 5830 and associated CA 
instances. Referring also to Fig. 102, the PLC I/O table sections are combined to form 
complete PLC I/O table 201 1 . 

[00430] The rules applied by compiler 8007 to build execution code 2009 and PLC I/O 

table 201 1 are stored in a code building table on database 9810. Referring to Fig. 106, 
exemplary code building table 8021 defines virtually all execution code which may possibly 
be required to support CA instances in a control bar chart assembled using resource editor 
9802. Thus, table 8021 defines code corresponding to every selectable CA type, every 
selectable CA request, every required CA type control device and characteristic, every 
selectable CA type device and characteristic, every selectable monitorable/controllable 
parameter or condition and every selectable diagnostic requirement/activity combination. 
[00431] While virtually all code which may be required is defined in table 8021, only 

code corresponding to required and selected (i.e. instantiated) CA types, characteristic, 
devices, HMI features and diagnostic combinations is compiled. Thus, for example, while 
code corresponding to a "pinset" CA type 8012 is defined in table 8021, if, upon selecting 
resources for control via resource editor 9802, a control engineer does not select and 
instantiate at least one "pinset" CA instance, the code corresponding to the "pin set" CA type 
8012 it not compiled. 

[00432] Table 8021 includes a CA type/request column 8023, a code column 8025, an 

I/O column 8026 and a parameterizing rule set (PRS) column 8027. Column 8023 lists every 
CA type which is selectable by the control engineer via resource editor 9802. In the present 
example, among other CA types, column 8023 includes the "SafeBulkHeadClampSet" type of 
which lstclamps is a single instance. For each CA type, column 8023 independently 
identifies each request in the CA type logic specification. For example, referring again to 
Fig. 85, each "SafeBulkHeadClampSet" CA type includes both an extend request and a retract 
request. Thus, in column 8023, under the "SafeBulkHeadClampSet" type 8029, each of the 
"extend" and "retract" requests 8033, 8035, respectively, are listed. 
[00433] In addition to requests which are associated with a logic specification, a 

"manual" request 8038 which is associated with a corresponding HMI specification is listed 
under each CA type. The manual request 8038 corresponds to execution code which may be 
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required to support manual operation of control mechanisms associated with a CA instance. 
Unlike code associated with a logic specification request (e.g. extend, retract), code 
associated with the manual request is generally only provided once in an execution code. 
[00434] Code column 8025 includes an RLL segment corresponding to each request in 

column 8023. Each RLL segment includes LL rungs corresponding to every possible control 
device and characteristic which may be associated with the corresponding request. Referring 
to Fig. 107, exemplary "SafeBulkHeadClampSet" extend request code segment 8032 is 
illustrated. Segment 8032 is abbreviated to simplify this explanation and, in reality, would 
include many more rungs. As illustrated, segment 8032 includes a "safety" rung 2045, a 
"lstclamps extend request" rung 8033 and a "Istclamps done" rung 8055. As illustrated, 
segment 8032 has already been partially parameterized to associate segment 8032 with the 
lstclamps CA instance. For example, many contacts and coils in Fig. 107 include a 
descriptor including the term lstclamps. It is contemplated that prior to compilation, the term 
"name" would appear in Fig. 103 A each time lstclamps appears. Upon compilation, the term 
"name" is replaced by the CA instance name (i.e. lstclamps). Similarly, other contact 
descriptors may be parameterized upon compilation. 

[00435] Safety rung 7045 renders the Istclamps extend request dependent on 

completion of at least one and perhaps several requests or conditions in bar chart 5830. For 
example, in Fig. 72, the Istclamps extend request 5701 should not begin until the dumps 
extend request 2041 has been completed at edge 5529. In addition, other conditions or 
request done states may have to occur prior to execution of the lstclamps extend request 
5701. These other conditions are reflected by the conditions corresponding to bar chart yield 
icons (e.g. 5703 in Fig. 72). 

[00436] Referring to Figs. 102 and 107, contacts and coils in Fig. 107 correspond to 

PLC I/O signals which have identical names in table 201 1. For example, when the status of 
"lstclamps II" 8046 turns from passive to active in table 201 1, contact "lstclamps II" 8046 
in rung 8055 closes, when coil "lstclamps extend done" 2727 in rung 8055 is excited, signal 
"lstclamps extend done" 2727 in table 201 1 changes from passive to active and so on. 
[00437] Referring still to Figs. 72 and 107, rung 2045 makes lstclamps extend request 

5701 dependent upon completion of dumps extend request 2041 and upon completion of 
other safety conditions (not specified). A completed request is referred to hereinafter as a 
"done" request. Rung 2045 includes a "dumps extend done" contact 2047 and first and 
second "safety" contacts 2049, 2051 in series with a "lstclamps extend request" coil 2053. As 
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with the lstclamps descriptors, the descriptor "dumps extend done" reflects parameterization 
which is consistent with bar chart 5830. Initially, a generic identifier such as "previous 
request done" is linked to contact 2047. Upon compilation, the phrase "previous request" 
would be replaced with the phrase "dumps extend". 

[00438] In the present example, rung 2045 has been configured to accommodate a 

maximum of two safeties and hence there are only two safety contacts 2049, 2051. However, 
it is contemplated that a "SafeBulkHeadClampSet" instance may require more than two 
safeties and for that purpose, code segment 8032 would include additional series contacts, 
one for each additional safety. 

[00439] Referring still to Figs. 72 and 107, when the dumps extend request 2041 is 

done, contact 2047 closes. Similarly, when each of the first and second safety conditions 
corresponding to contacts 2049 and 2051 are done, contacts 2049 and 2051, respectively, 
close. When all of contacts 2047, 2049 and 2051 close, coil 2053 is excited. When 
"lstclamps extend request" coil 2053 is excited, related "lstclamps extend request" contacts 
(e.g. contact 8035 in rung 8033) close. Thus, rung 8033 is dependent on each of the 
conditions associated with contacts 2047, 2049 and 2051 occurring. 
[00440] Because rung 2045 is a safety rung, the conditions represented by contacts 

2047, 2049 and 2051 need not be maintained during execution of lstclamps extend request 
5701. Thus, branches 2091 and 2093 are provided which, after the conditions corresponding 
to contacts 2047, 2049 and 205 1 have been met, override the safety conditions and thereby 
enable the extend request despite the current status of the safety conditions. Branch 2091 
includes a "lstclamps safety override" contact 2095 in series with a "not lstclamps retract 
request" contact 2101, the series pair in parallel with contacts 2047, 2049 and 2051. Branch 
2093 includes a "lstclamps safety override" coil 2097 in parallel with coil 2053. When the 
term "not" is included in a contact label, the term "not" indicates the opposite of the condition 
modified thereby. For example, with respect to contact 2101, "not" means that a lstclamps 
retract request has not been made. After a lstclamps retract request is made, contact 2101 
opens. 

[00441] In operation, referring to Figs. 72 and 107, after dumps extend request 2041 

has been completed, contact 2047 closes. Similarly, when conditions corresponding to 
contacts 2049 and 2051 occur, contacts 2049 and 2051 close causing each of coils 2053 and 
2097 to excite. Coil 2097 causes contact 2095 to close. It is assumed that the lstclamps 
retract request is not pending and therefore contact 2101 remains closed. Thus, after all of 
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contacts 2047, 2049 and 2051 close, those contacts are bypassed by closed contacts 2095 and 
2101 until a lstclamps retract request occurs which opens contact 2101. During this bypass 
period, coil 2053 remains excited and therefore contacts associated therewith remain closed. 
When contact 2101 opens, (i.e. when a lstclamps retract request occurs), coil 2097 is no 
longer excited and therefore contact 2095 opens and safeties 2047, 2049 and 2051 are again 
functional to limit the next lstclamps extend request. 

[00442] Rung 8033 is designed to cause lstclamps to extend when "lstclamps extend 

request" coil 2053 or some other identically named coil is excited. Rung 8033 includes a 
"lstclamps extend request" contact 8035 and first and second interlock contacts 2077 and 
2079, respectively, in series with a parallel coil arrangement including coils 8037, 8039, 8041 
and 8043 corresponding to outputs 01, 02, 05 and 06, respectively. 
[00443] The interlock contacts 2077 and 2079 render a corresponding request 

dependent on completion and maintenance of corresponding conditions. Thus, if an interlock 
condition ceases to exist during execution of a dependent request, request execution is halted. 
Referring also to Fig. 72, interlock conditions are reflected by the conditions corresponding 
to bar chart stop icons (e.g. 5707). Each of contacts 2077 and 2079 are linked to a separate 
interlock condition. When an interlock condition is done, the corresponding contact 2077 or 
2079 is closed. When an interlock condition is not done the corresponding contact is open. 
[00444] As with safeties above, a "SafeBulkHeadClampSet" CA instance 8029 may be 

interlocked to more than two conditions and in this case, additional contacts, one for each 
additional interlock contingency, would be provided in series with contacts 2077 and 2079. 
[00445] Referring to Figs. 102 and 107, when all contacts 8035, 2077 and 2079 are 

closed, coils 8037-8043 are excited or activated and their status in a PLC I/O table 201 1 is 
updated. When the PLC I/O table 201 1 is updated, the active output signals cause valves 
associated therewith via I/O pins (e.g. PI, P2, etc.) to provide air to cylindicators linked 
thereto to extend associated clamps. 

[00446] Referring still to Fig. 107, "lstclamps extend done" rung 8055 indicates when 

a lstclamps extend request has been completed or is done. Rung 8055 includes, among other 
components, a "lstclamps II" contact 8049, a "lstclamps 13" contact 8057, a "lstclamps 15" 
contact 8052 and a "lstclamps 17" contact 8054 in series with a "lstclamps extend done" coil 
2727. Referring also to Fig. 85, contacts 8049, 8057, 8052 and 8054 correspond to 
cylindicator extended solenoid sensor signals II, 13, 15 and 17. When each of signals II, 13, 
15 and 17 is active, contacts 8046, 8057, 8052 and 8054, respectively, close and coil 2727 is 
excited indicating that the lstclamps extend request has been completed. Although not 
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illustrated, referring also to Fig. 72, when coil 2727 is excited, a contact corresponding to 
edge 5527 closes indicating that the lstclamps extend is done and that, at least with respect to 
that contingency, the "operator-station 1 Load-Part" request 2107 can begin. 
[00447] Other rungs and branches which may be required to support parameterization 

include diagnostic rungs and branches corresponding to diagnostic functions which are 
selectable via diagnostics editor 9806 (see Fig. 90). Diagnostic functions are listed in the 
diagnostics table in Fig. 87. 

[00448] While it is contemplated that segment 8032 would include LL rungs to support 

virtually every possible diagnostic requirement/activity, in the interest of simplifying this 
explanation, only two exemplary rungs are illustrated and described. For example, referring 
to Fig. 87, with respect to cylindicator 9425, lstclamps cylinder failure requirement 9622 
occurs when each of proximity sensor inputs II and 12 indicate proximity of a valve piston. 
Upon the occurrence of requirement 9622, a diagnostics message is required as specified by 
activity 8517. 

[00449] In Fig. 107, branch 8077 defines code to recognize requirement 9622 facilitate 

activity 85 17 when requirement 9622 occurs. To this end, branch 8077 is in series with 
contact 8046 and includes "lstclamps 12" contact 8049 in series with "lstclamps cylindicator 
failure" coil 8048. Contacts 8046 and 8049 correspond to inputs II and 12, respectively, and 
close when corresponding proximity sensor signals are active. When both contacts 8049 and 
8046 close (i.e. requirement 9622), coil 8048 is excited. Referring to Figs. 87, 102 and 107, 
coil 8048 update a "lstclamps cylinder failure" signal 8048 status. Referring also to Fig. 95, 
when coil 8048 is excited, HMI 8437 generates a diagnostic message indicating failure as 
described in more detail below. 

[00450] Referring still to Figs. 87 and 107, when a lstclamps extend request occurs 

and conditions associated with contacts 2077 and 2079 occur, if extended proximity sensor II 
remains passive (i.e. "lstclamps II Passive" requirement 9624), an error occurs and activity 
9626 is required. Segment 8032 includes branch 8085 which defines code to recognize 
requirement 9624 and facilitate activity 9626 when requirement 9624 occurs. Branch 8085 is 
in series with contacts 8035, 2077 and 2079, and includes contact 8111 and a series coil 
8113. Contact 8111 corresponds to the opposite of input II (i.e. if II is active, "not II" is 
passive and vice versa). Thus, if contacts 8035, 2077 and 2079 close to perform an extend 
request and contact 8111 remains closed (i.e. II is passive), coil 81 13 is excited. When coil 
81 13 is excited, HMI 8437 generates the diagnostic message required by activity 9262. 
Although not illustrated, a delay may be provided between contact 8111 and coil 91 13 so that 
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coils 8037, 8039, 8041 and 8043 and related mechanical mechanisms have a reasonable 
amount of time to cause lstclamps to extend prior to diagnostic activity 9626 occurring. 
[00451] As indicated above, segment 8032 is extremely abbreviated and is 

contemplated that many other LL rungs will be provided in each LL segment. For example, 
additional diagnostic rungs will be provided as well as rungs to support other parameterizable 
features such as latches, request restartability and so on. These additional rungs have not 
been described here in order to simplify this explanation and because they are not needed for 
an understanding of the present invention. 

[00452] Referring still to Figs. 106 and 107, although not illustrated, a code segment 

8115 corresponding to "SafeBulkHeadClampSet" CA type retract request 8035 is similar to 
code segment 8032 except that, instead of defining code for controlling an extend request, the 
retract segment would define code for controlling a retract request. 
[00453] Referring now to Figs. 106 and 108, an exemplary manual request code 

segment 8034 is illustrated. Referring also to Fig. 86, each of lstclamps outputs 01 through 
06 may be selected to be controlled during manual system operation. In addition, each of the 
extend and retract requests may also be selected for manual control. Thus, LL rungs for 
controlling each of outputs 01-06 and extend and retract requests must be defined such that, if 
selected for compilation, the rungs can be provided in the execution code. However, unlike 
requests (e.g. extend, retract, etc.) which may be performed more than once during an 
execution code cycle and therefore may have to be represented more than once during a 
cycle, manual control code need only be provided once in an execution code. 
[00454] In addition, generally the location of manual code in an execution code is 

unimportant. Thus, in the present example, it is assumed that, if manual operation is selected 
via HMI editor 9804 as indicated above and therefore must be supported by execution code, 
the manual code is placed after the first occurrence of any related request. For example, 
referring to Figs. 72 and 106, if lstclamps extend request 5701 is the first 
"SafeBulkHeadClampSet" request in bar chart 5830, immediately after compiling code for 
extend request 5701, if selected via HMI editor 9804, manual code is compiled and linked to 
the end of the extend request code. Thereafter, manual segment 8034 does not again appear 
in the execution code. 

[00455] As in the extend request code segment 8032 described above, contacts and 

coils in manual segment 8034 correspond to similarly labeled and numbered signals in table 
102. Exemplary manual segment 8034 comprises rung 8087 including a "manual" contact 
2131 and a plurality of branches 8063, 8065, 8091 and 8093. 
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[00456] If manual control is selected for compilation for lstclamps, upon compilation 

manual contact 2131 is linked to an HMI control button which, when activated, closes contact 
2131. Although not illustrated, it is also contemplated that when contact 2131 is closed, the 
normal sequence of requests as specified by bar chart 5830 is halted until normal operation is 
again actively selected. While contact 2131 remains closed, branches 8063, 8065, 8091 and 
8093 may be functional depending on if related outputs or requests (i.e. 01-06, extend, 
retract) were previously selected for compilation. 

[00457] Branch 8063 defines code for controlling lstclamps 01 via HMI 8437 and 

includes a contact 2133 and a coil 8103. If selected to be compiled, contact 2133 is linked to 
an HMI control button which, when activated, closes contact 2133. When contact 2133 
closes, coil 8103 excites which closes a related lstclamps 01 contact. Branch 8065 is similar 
to branch 8063 except that a contact corresponds to a button for controlling output 06 and a 
coil corresponds to output 06. Although not illustrated, branches like branch 8063 are also 
provided for each of outputs 02-05. 

[00458] Branch 8091 defines code for manually controlling the lstclamp extend 

request. Branch 8091 includes a contact 2135 and a coil 8107. If selected to be compiled, 
contact 2135 is linked to an HMI control button which, when activated, closes contact 2135. 
When contact 2135 is closed, coil 8107 excites and closes related "lstclamps extend request" 
contacts. Referring also to Fig. 107, when "lstclamps extend request" coil 8107 excites, 
contact 8035 closes, causing outputs 01, 02, 05 and 06 to excite (assuming conditions 
associated with contacts 2077 and 2079 are met) which in turn cause control mechanisms 
linked thereto to extend clamps associated with the lstclamps CA instance. Rung 8093 is 
similar to rung 8091 except that, instead of defining code for manual control of the extend 
request, rung 8093 defines code for manual control of the retract request. 
[00459] Many of the characteristics and, indeed, for each CA type, even some of the 

control devices, are optional and therefore may or may not be selected for subsequent 
compilation. Therefore, referring again to Figs. 106, 107 and 108 while each code segment 
(e.g. 8032, 8034) defines LL rungs to support virtually every required and parameterizable 
CA characteristic for a request, every LL rung or branch in a code segment which 
corresponds to a parameterizable (i.e. selectable or de-selectable) CA feature is provided in 
series or in parallel with a switch so that the rung or branch can be discarded upon 
compilation. When a series switch is closed or a parallel switch is open, the corresponding 
rung is compiled and when a series switch is open or a parallel switch is closed, the 
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corresponding rung is discarded upon compiling. In Figs. 107 and 108 switches are identified 
by triangles and are labeled with descriptors "Sn" where n is an integer (e.g. SI, S2, etc.) 
[00460] Rungs which are required within a CA type do not include switches. For 

example, referring to Figs. 85 and 107, two position valve 9421 is required in the 
"SafeBulkHeadClampSet" CA type. Therefore, no switches are in series or in parallel with 
coils 8037 and 8039 (corresponding to the required two position valve 9421). Similarly, it is 
required that the "previous request done" requirement be met prior to executing the lstclamps 
extend request and therefore, no switches are in series or in parallel with "dumps extend 
done" contact 2047. 

[00461] However, spring return value 9423 is optional (i.e. in the present example may 

be selected or de-selected using resource editor 9802). Thus, switches are provided within 
code segment 8032 which, when open, effectively de-select code corresponding to spring 
return value 9423 and, when closed, select code for valve 9423. In Fig. 107, switches S3 and 
S4 correspond to valve 9423. Thus, if switches S3 and S4 are open, upon compilation 
branches including coils 8041 and 8043 are eliminated from segment 8032. 
[00462] Similarly, referring to Figs. 87 and 107, each of diagnostics branches 8085 and 

8077 is optional and therefore, switches S5 and S6 are provided in those rungs, respectively. 
When one of switches S5 or S6 is opened, a corresponding branch is eliminated upon 
compilation. 

[00463] Moreover, it is contemplated that the lstclamps extend request may not be 

contingent upon additional safeties and interlocks. In this case, safety contacts 2049 and 
2051 and interlock contacts 2077 and 2079 should be eliminated. To this end, switches SI, 
S2, S7 and S8 are provided in parallel with contacts 2049, 2051, 2077 and 2079, respectively. 
When one of switches SI, S2, S7 or S8 is closed, a parallel contact is eliminated upon 
subsequent compilation. 

[00464] Furthermore, referring to Figs. 85 and 107, 2nd, 3rd and 4th cylindicators 

9427, 9429 and 9431 are optional. In rung 8055, if second cylindicator 9427 is not included 
in lstclamps, contact 8057 corresponding to the second cylindicator extended proximity 
sensor signal 13 must be eliminated in segment 8032. Similarly, if cylindicator 9429 is not 
included, contact 8052 must be eliminated, and if cylindicator 9431 is not included, contact 
8054 must be eliminated. To this end, switches S9, S10 and SI 1 are in parallel with contacts 
8057, 8052 and 8054, respectively. If switch S9, S10 or SI 1 is closed a corresponding 
parallel contact is removed from segment 8032 upon compilation. 
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[00465] Referring to Figs. 86 and 108, controllability of outputs 01-06 and 

controllability of extend and retract requests is also optional. Therefore, switches SI 2, SI 3, 
S14 and SI 5 are provided in series with branches 8063, 8065, 8091 and 8093, respectively. 
When one of switches S12-S15 is open the corresponding branch is eliminated upon 
compilation. 

[00466] Referring once again to Fig. 106, column 8026 includes a single generic PLC 

I/O table segment for each CA type independent of the number of requests which correspond 
to the CA type. Generic segment 8060 corresponds to "SafeBulkHeadClampSet" type 8029. 
[00467] Segment 8060 includes a PLC signal list corresponding to an unparameterized 

"SafeBulkHeadClampSet" CA type. In other words, the PLC signal list in table 8060 
includes signals which must be included in a PLC I/O table when a "SafeBulkHeadClampSet" 
CA type instance is instantiated, regardless of parameterization. For example, referring also 
to Fig. 107, for CA type 8029, generic segment 8060 includes every contact in segment 8032 
which is not in series or in parallel with a switch SI -SI 1. In addition, referring to Fig. 108, 
table 8060 includes every contact in segment 8034 which is not in series or in parallel with 
one of switches S12-S15. In segment 8034 all contacts are in series or parallel with at least 
one of switches S12-S15 and therefore, unless also included in one of segments 8032 or 8035 
none of those contacts is included in the initial PLC signal list. 
[00468] Generic segment 8060 is modified by compiler 8007 as a function of 

parameterization. Eventually, in the present example and after compilation, generic segment 
table 8060 looks like table 201 1 including signals in column 2015 corresponding to every 
contact and coil in parameterized and compiled code segments 8032, 8115 and 8034 (i.e. 
corresponding to all "SafeBulkHeadClampSet" requests). 

[00469] Referring still to Fig. 106, PRS column 8027 includes a separate PRS table 

corresponding to each request in column 8023. An exemplary PRS table 8201 which 
corresponds to the "SafeBulkHeadClampSet" CA type extend request 8033 is illustrated. 
PRS table 8201 includes a parameterization column 8203, a code modification column 8205 
and a PLC I/O table modification column 8207. 

[00470] Column 8203 includes a list of possible parameterizations corresponding to 

the CA type and request in column 8023. Each parameterization in column 8203 is 
associated with a separate one of the flag boxes in one of specifications 9002, ( see Fig. 85), 
9006 (see Fig. 86) or 9008 (see Fig. 87) or is associated with a yield or stop icon in Fig. 72. 
For example, referring also to Fig. 85, one parameterization 8209 includes "flagged box 
9480a" indicating selection of spring return valve 9423. Referring to Figs. 87 and 106, 
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second exemplary parameterization 2731 is "flagged box 9490" indicating selection of the 
Istclamps extend request to be controlled via an HML Many other parameterizations are 
contemplated and would be listed in column 8203. 

[00471] Column 8205 includes modifications to the code segments in column 8025 

which correspond to specific parameterizations in column 8203. For example, modification 
8217 corresponding to the "flagged box 9480a" parameterization 8209 is to close switches S3 
and S4. Referring also to Fig. 107, when switches S3 and S4 are closed, coils 8041 and 8043 
corresponding to outputs 05 and 06 are included in code segment 8032. Modification 8215 
corresponding to "flagged box 9490" parameterization 2731 is to close switch SI 4. Referring 
to Fig. 108, when switch S14 is closed, rung 8091 is included in segment 8034 and manual 
control of the 1 stclamps extend request is supported by segment 8034. 
[00472] Referring still to Fig. 106, column 8207 lists PLC I/O table modifications 

corresponding to parameterizations in column 8203. For example, referring also to Fig. 85, 
where box 9840a is flagged (i.e. parameterization 8209), outputs 05 and 06 are added to 
segment 8060 according to modification 8221. Similarly, where box 9490 is flagged (i.e. 
parameterization 2731), signal "Istclamps extend request control" corresponding to contact 
2135 (see Fig. 108) is provided in segment 8060 to facilitate manual control of the Istclamps 
extend request via an HMI, and so on. 

[00473] Although not illustrated in detail, PRS tables 8301 and 8303 which are similar 

to table 8201 are provided for each of retract request 8035 and manual request 8038 and are 
provided for each request associated with other CA types in column 8023. 
[00474] Referring now to Figs. 72 85, 86, 87 and 105, in the present example, after 

compiler 8007 compiles and links execution code segments for each request prior to 
Istclamps extend request 5701, deconvolver 8002 causes parser 8005 to provide logic, HMI 
and diagnostic specifications 9002, 9006 and 9008, respectively, which correspond to 
Istclamps extend request 5701 to compiler 8007 and deconvolver 8002 provides the S/I table 
which corresponds to the "Istclamps extend" request to compiler 8007. 
[00475] The S/I table (not illustrated) is simply a table which lists all Istclamps extend 

request contingencies including the previous request from bar chart 5830 ( see Fig. 72), and 
all safeties and interlocks listed in yield and stop icons, respectively, which are linked to the 
front edge of the 1 stclamps extend request. Thus, referring to Fig. 72, the S/I table for 
Istclamps extend request 5701 includes "dumps extend" request 2041 and any contingencies 
from icon 5703. 
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[00476] Referring also to Fig. 109, an exemplary compiling process performed by 

compiler 8007 is illustrated. At block 8305, compiler 8007 either receives an end sequence 
signal or an S/I table from deconvolver 8002. The end sequence signal indicates that 
information corresponding to the last request in bar chart 5830 has been compiled and that 
final compilation steps should be performed by compiler 8007. At decision block 8315, 
compiler 8007 determines if an end sequence signal has been received. If an end sequence 
signal has been received control passes to process block 8317. In the present example, 
lstclamps extend request 5701 is not the last request in chart 5830 and therefore control 
passes to block 8306. At block 8306 compiler 8007 receives specifications 9002, 9006 and 
9008 and the S/I table corresponding to the lstclamps instance. At block 8307 compiler 8007 
accesses code table (see Fig. 106) 8021 via bus 8013, identifies the "SafeBulkHeadClampSet" 
CA type 8029 and the extend request 8033 corresponding to lstclamps extend request 5701 
and retrieves code segment 8032, generic segment 8060 and PRS 8201. Continuing, at block 
8309 compiler 8007 gleans parameterization information from logic specification 9002, HMI 
specification 9006, diagnostic specification 9008 and the S/I table. At process block 831 1 
compiler 8007 applies the rules from PRS table 8201 to the gleaned information to modify 
the code segment 8032 by opening/closing rung switches and to modify PLC I/O table 
segment 8060 as described above. In addition, at block 8311 compiler 8007 substitutes the 
CA name (e.g. lstclamps) for generic contact and coil descriptions (e.g. "name") in code 
segment 8032 and in segment 8060. 

[00477] Next, at process block 83 13, compiler 8007 links the parameterized execution 

code segment 8032 to previously compiled segments to continue to form a complete LL 
program and adds the parameterized segment 8060 to other I/O specifications corresponding 
to previously compiled segments. 

[00478] Referring again to Figs. 72 and 101, at this point a complete execution code 

2009 for controlling mechanical resources as required by bar chart 5830 has been provided. 
In addition, referring to Fig. 102, columns 2015 and 2017 of PLC I/O table 201 1 have been 
defined. Next, I/O card pins have to be assigned to I/O signals in column 2015. 
[00479] Herein it is assumed PLC card 2003 includes a sufficient number of I/O 

terminals to control and monitor the control system corresponding to bar chart 5830 as 
parameterized by the CA instances related thereto. At block 8317 compiler 8007 assigns 
signals from PLC I/O table 201 1 column 2015 to I/O card terminals P-l, P-2, ... P-N to fill in 
column 2019 and complete table 201 1. At block 8321, compiler 8007 provides the execution 
code and PLC I/O table 201 1 . 
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[00480] Referring again to Fig. 90, the execution code 2009 and PLC I/O table 201 1 

are provided to database 9810 for storage and subsequent access. In addition, the execution 
code 2009 and I/O table 201 1 are provided to PLC 9814. Referring to Fig. 101,1/0 table 
201 1 is also provided to schematic compiler 801 1 via bus 8013. 

[00481] At this point all of the execution code for controlling the process and control 

mechanisms associated with bar chart 5830, the code for supporting HMIs as required by 
HMI specifications and the code for supporting diagnostics as required by diagnostic 
specifications has been provided. 

[00482] It should be appreciated that while the compilation example above is described 

in the context of a system of CAS which does not support status based diagnostics, a similar 
process would be performed where CAS include status based diagnostics specifications, the 
only difference being that the generated code would include additional status based 
diagnostics code. The additional code would facilitate next event reporting such that, when a 
next event fails to occur, a PLC running the code would indicate the next event to occur 
thereby indicating symptoms to a system user which the user could then use to determine the 
likely cause of failure. In this regard, the diagnostics code, a diagnostics processor and a 
driver which indicates the next event to occur operate together as a diagnostics agent to report 
failure non-occurring events. This aspect of the invention is described in more detail below. 
[00483] b. HMI Compiler 

Referring again to Figs. 84 and 101, HMI compiler 8009 receives HMI specification 
9006 and diagnostic specification 9008 from code compiler 8007. Exemplary HMI 
specification table 9460 is illustrated in Fig. 86 while exemplary diagnostic specification 
table 9600 is illustrated in Fig. 87. With respect to HMI table 9460, compiler 8009 gleans 
information from table 9460 and, referring also to Fig. 110, applies rules from an HMI 
building table 8401 to the gleaned information to construct an HMI screen including 
indicators and control buttons and to link the indicators and buttons to PLC signals. 
[00484] To this end, building table 8401 defines virtually all HMI indicator and control 

buttons which may possibly be required to support monitoring and control of CA 
characteristic. Table 8401 includes a CA type column 8403, a monitorable column 8405 and 
controllable column 8407. Monitorable column 8405 defines HMI indicators and PLC signal 
links whereas controllable column 8407 defines control buttons and associated PLC signal 
links. CA type column 8403 includes a list of every possible CA type which may be selected 
by a control engineer using resource editor 9802. For the purposes of this explanation, 
"SafeBulkHeadClampSet" CA type 8029 is listed in column 8403. 
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[00485] Monitorable column 8405 is divided into subcolumns including an I/O column 

841 1, a "label" column 8413 and a "link" column. I/O column 841 1 includes a list of all 
monitorable inputs and outputs corresponding to each specific CA type in column 8403. 
Thus, referring to Figs. 86 on 110, because an exemplary "SafeBulkHeadClampSet" CA type 
8029 may include monitorable outputs 01-06 and monitorable inputs I-1-I8, each of outputs 
01-06 and each of inputs I- 1-18 are included in column 841 1 corresponding to the 
"SafeBulkHeadClampSet" CA type 8029. In order to simplify Fig. 110, only an abbreviated 
list (i.e., 01, 02, 03 ... II, 12 ...) is provided in column 8411. 

[00486] Column 8413 includes a separate label corresponding to each I/O in column 

841 1 . Each label in column 8413 defines a descriptor for an HMI indicator. For example, for 
01 in column 841 1, the label in column 8413 is "2-position value hot extend output" 8727 
which describes the hot output 01 of two-position valve 9421 in Fig. 85. For 02, in column 
841 1, the label in column 8413 is "2-position value common extend out" 8729 which 
describes the common output 02 of two-position valve 9421 in Fig. 85. For II in column 
8411 the label is "1st cylindicator extend signal" 8731 which describes first cylindicator 9425 
input II in Fig. 85 and for 12 in column 841 1 the label is "1st cylindicator retract signal" 8733 
which describes first cylindicator 9425 input 12 in Fig. 85. 

[00487] Column 8725 includes a PLC signal link for each I/O in column 841 1 . Each 

link in column 8725 includes a generic descriptor "name" which, upon compilation, is 
replaced with the CA instance name. Thus, in the present example, general descriptors 
"name" in Fig. 110 is replaced with lstclamps upon compilation. Link "name" II corresponds 
to II in column 841 1, link "name" 12 corresponds to 12 and so on. After compilation, link 
"name" II and link "name" 12 are replaced by "lstclamps 11" and "lstclamps 12," respectively, 
which link associated indicators with similarly identified PLC signals 8046 and 8049, 
respectively, in table 201 1 (see Fig. 102). 

[00488] Referring still to Fig. 110, controllable column 8407 is also divided into 

subcolumns including an I/O column 8417, a "label" column 8419 and a "link" column 8735. 
Column 8417 includes a list of all I/O and requests which may be selected to be controllable 
via HMI editor 9804 and which are associated with a corresponding CA type. Referring also 
to Fig. 86, for the "SafeBulkHeadClampSet" CA type 8029, outputs which may possibly be 
selected for control include outputs 01 through 06 and requests which may possibly be 
selected for control include extend and retract requests. To simplify Fig. 1 10, only outputs 01 
and 02 are listed. 
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[00489] Column 8419 includes a separate label corresponding to each I/O or request in 

column 8417. Each label in column 8419 defines a descriptor for an HMI button. For 
example, for "extend" in column 8417 the label in column 8419 is "extend" and for "retract" 
in column 8417 the label in column 8419 is "retract." 

[00490] Column 8735 includes a PLC signal link for each I/O or request in column 

8417. Once again, upon compilation the generic descriptors "name" are replaced with CA 
instance name "lstclamps." Thus, after compilation, requests extend and retract are linked to 
"lstclamps extend request control" 2135 and "lstclamps retract request control" 2136 signals, 
respectively, in table 201 1 ( see Fig. 102). 

[00491] Upon compilation, referring to Figs. 86 and 110, compiler 8009 identifies all 

selected I/O and requests for monitoring and control in table 9460, identifies the selected I/O 
and requests in columns 841 1 and 8417 and uses information in table 8401 to build an HMI 
configuration/linking table like table 2027 illustrated in Fig. 103. The compilation process is 
described in more detail below. 

[00492] Referring to Figs. 87 and 105, with respect to diagnostics table 9600, compiler 

8009 gleans information from diagnostic specification table 9600 and, referring also to Fig. 
113, applies diagnostics building table 8739 to the gleaned information to construct a 
parameterized diagnostics linking table (see Fig. 104). 

[00493] To this end, diagnostics building table 8734 includes a "requirement" column 

8741, a "text" column 8743 and a "link" column 8745. Referring to Figs. 87 and 1 1 1, column 
8741 includes an entry corresponding to each requirement in column 9604 and text column 
8743 includes an entry corresponding to each activity in column 9606. In particular, among 
other requirements and activities, "lstclamps cylinder failure" requirement 9622 and 
"lstclamps extend sensor error" requirement 9624 and associated text activities are listed in 
columns 8741 and 8743. 

[00494] Upon compilation, referring to Figs. 87 and 111, compiler 8009 identifies all 

selected diagnostics requirements for supporting in table 9600 identifies the selected 
requirements in column 8741 and uses information in table 8739 to build diagnostics linking 
table like table 2751 illustrated in Fig. 104. 

[00495] Referring to Fig. 1 12, an exemplary compiling process performed by compiler 

8009 is illustrated. Referring also to Figs. 101 and 105, at decision block 8424, processor 
8009 determines if deconvolver 8002 has provided an end sequence signal indicating the end 
of bar chart 5830. IF an end sequence signal has been provided, control skips to block 8435 
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where compiler 8009 provides both HMI linking table 2027 ( see Fig. 103) and diagnostics 
linking table 2751 (see Fig. 104). In the present example, lstclamps extend request 5701 is 
not the last request in chart 5830 and therefore control passes to block 8425. 
[00496] At block 8425, referring also to Figs. 86 and 87, compiler 8009 receives HMI 

and diagnostic specifications 9006, 9008, respectively, corresponding to the lstclamp CA 
instance. At process block 8427, compiler 8009 gleans HMI requirements from HMI 
specification 9006 and gleans diagnostic requirements from the diagnostic specification 9008. 
To this end, compiler 8009 identifies clear and flagged boxes in each of columns 9464 and 
9466, identifies CA instance name lstclamps and identifies clear and flagged boxes in 
column 9604. 

[00497] Referring to Figs. 105, 1 10 and 1 12, at block 8429 compiler 8009 applies table 

8401 to the gleaned information and builds parameterized HMI linking table 2027 as 
illustrated in Fig. 103. To this end, for every selected monitorable I/O (i.e., I/O in Fig. 86 
which has been flagged), compiler 8009 identifies the selected I/O in column 841 1 of table 
8401 and copies the label and link information corresponding thereto into parameterized HMI 
linking table 2027. Similarly, for every selected I/O and request to be controlled, compiler 
8009 identifies the selected I/O or request in column 8417 of table 8401 and copies label and 
link information into parameterized HMI linking table 2027. 

[00498] Similarly, referring to Figs. 105 and 1 12 at block 8429, compiler 8009 applies 

table 8739 to the gleaned information and builds parameterized diagnostics linking table 2751 
as illustrated in Fig. 104. To this end, for every selected requirement in table 9600 ( see Fig. 
87), compiler 8009 identifies the requirement in column 8741 of table 8739 and copies the 
text and link information corresponding thereto into parameterized diagnostics table 2751. 
[00499] At block 8433, compiler 8009 substitutes CA instance name lstclamps for 

generic descriptor "name" and may substitute other specific descriptors as required. 
Therefore, control passes back to block 8424. 

[00500] After specifications corresponding to the last request in chart 5830 have been 

compiled, control passes to process block 8435 where parameterized HMI and diagnostics 
linking tables 2027 and 2751, respectively, are provided. 

[00501] Referring also to Fig. 90, HMI and diagnostics linking tables 2027 and 2751 

are provided to HMI workstation 8437 via a bus 8439. It is assumed HMI 8437 includes 
software which, with a simple specification such as tables 2027 and 2751, can configure a 
screen like exemplary screen 7005 illustrated in Fig. 95. Station 8437 is linked to PLC 9814 
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via a two-way bus 8441 for controlling PLC 9414 during manual PLC operation and for 
monitoring PLC 9814 during both normal PLC operation and manual operation. 
[00502] At this point a complete HMI configuration for both manual and automatic 

control and monitoring of the control process associated with bar chart 5830 and 
corresponding CA instances have been provided. In addition, tables for linking HMI tools 
and diagnostic activities to PLC signals have been provided. 
[00503] c. Schematic Compiler 

Referring again to Figs. 72, 84, 85 A and 105, as compilers 8007 and 8009 process 
specifications for the lstclamps CA extend request 5701, schematic compiler 801 1 
simultaneously processes lstclamps schematic specification 9004. Compiler 8011 gleans 
information from schematics specification 9004 and, referring also to Fig. 113, applies rule 
from a schematic building table 8501 to the gleaned information to build a parameterized 
control system schematic. 

[00504] Exemplary schematic building table 8501 includes a CA type column 8503, a 

default schematic column 8505, and a parameterizing rule set (PRS) column 8507. Column 
8503 includes a list of each CA type which a control engineer may select using resource 
editor 9802. For the purposes of the present explanation, a "SafeBulkHeadClampSet" CA 
type 8029 is included in column 8503. 

[00505] Default schematic column 8505 includes a separate default schematic 

corresponding to each CA type in column 8503. With respect to the 

"SafeBulkHeadClampSet" CA type 8029, the default schematic is illustrated in block form as 
851 1. As explained above, for the "SafeBulkHeadClampSet" CA type 8029, required control 
devices include a two-position valve and at least a first cylindicator. Therefore, default 
schematic 851 1 includes a schematic illustration showing a two-position valve and a single 
cylindicator linked together in an operative manner. 

[00506] PRS column includes a separate table corresponding to each CA type in 

column 8503. Table 8513 corresponds to the "SafeBulkHeadClampSet" CA type 8029 and 
includes a parameterization column 8515 and a schematic modification column 8517. 
[00507] Referring to Figs. 85A and 113, column 8515 includes a list of possible 

parameterizations which correspond to schematic specification 9004. Column 8517 includes 
one or more schematic modifications corresponding to each parameterization in column 
8515. For example, the schematic modification corresponding to a "flagged box 9480F 
parameterization is that a spring return valve representation should be added to default 
schematic 851 1 and linked accordingly. Thus in Fig. 85 A, when spring return valve 9523 is 



-93- 



selected by placement of a flag in box 9480f, the corresponding spring return valve schematic 
is added to schematic 851 1 upon compilation. 

[00508] Similarly, the modification corresponding to a "flagged box 9482f ' 

parameterization is that a second cylindicator schematic should be added to the default 
schematic 851 1 and linked accordingly. Although not illustrated, other parameterizations and 
associated schematic modifications are contemplated. Default schematics and associated 
PRSs are provided in table 8501 for each CA type listed in column 8503. 
[00509] Referring to Fig. 90, schematic I/O which are to be linked to PLC 9814 are 

labeled with PLC signal names. For example, referring to Figs. 85 and 113, two-position 
valve 9421 receives four PLC outputs 01-04 and therefore schematic 851 1 illustrates four 
PLC outputs 01-04 for linking to PLC 9814. The schematic outputs 01-04 are labeled 
"lstclamps 01", "Istclamps 02", "lstclamps 03", and "lstclamps 04". If selected for 
compilation, spring return valve 9423 includes outputs "lstclamps 05", and "lstclamps 06", 
and corresponding schematic outputs for valve 9423 are so labeled. Cylindicator inputs II 
through 18, if selected are similarly labeled on the schematic. 

[00510] After a parameterized schematic diagram for the lstclamps CA instance has 

been provided, the diagram is linked to previously parameterized diagrams corresponding to 
other CA instances associated with bar chart 5830. Once all parameterized schematics have 
been linked and after compiler 8007 has generated a complete PLC I/O table 201 1 (see Fig. 
102), table 201 1 is provided to schematic compiler 801 1. Compiler 801 1 then schematically 
links I/O card pin numbers to similarly named schematic I/O. For example, "lstclamps 01" is 
schematically linked to the pin number corresponding to "lstclamps 01" in table 201 1, 
"lstclamps II" in the schematic is schematically linked to the pin number corresponding to 
"lstclamps II" in table 201 1 and so on. 

[005 1 1] Referring now to Fig. 1 14, an exemplary compiling process performed by 

compiler 801 1 is illustrated. At decision block 8533 compiler 801 1 determines if an end 
sequence signal indicating the end of bar chart 5830 has been received from deconvolver 
8002. Where an end sequence signal has been received control passes to block 8535. Where 
an end sequence signal has not been received control passes to block 8525. 
[005 12] Referring also to Fig. 85A, at block 8525 compiler 801 1 receives lstclamp 

schematic specification 9004. At process block 8527 compiler 801 1 gleans information from 
schematic specification 9004. Referring also to Fig. 1 13, at block 8529 compiler 801 1 
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accesses schematic building table 8501, identifies the CA type as a "SafeBulkHeadClampSet" 
type and identifies the default schematic 851 1 and PRS table 8513. 
[00513] Continuing, at process block 8531, compiler 801 1 parameterizes default 

schematic 851 1 as a function of gleaned information and in the manner specified by PRS 
table 8513 and links the parameterized schematic to previously parameterized schematics. 
Thereafter control passes back up to decision block 8533. 

[00514] After the end sequence signal is received and control passes to block 8535, 

referring also to Figs. 102 and 105, compiler 801 1 receives PLC I/O table 201 1 from code 
compiler 8007 and schematically links schematic I/O to pin numbers in column 2019 which 
correspond to signals in column 2015 which have names in common with the schematic I/O. 
Thereafter, at block 8536, compiler 801 1 provides the complete parameterized control system 
schematic. 

[00515] Referring again to Fig. 90, the schematic can be stored on database 9810 

and/or can be printed out via printer 8436. 
[00516] d. Simulation Compiler 

Referring to Fig. 88 and 105, as compilers 8007, 8009 and 801 1 compile 
specifications corresponding to CA instance lstclamps, simulation compiler 8010 
simultaneously receives simulation specification 9300 corresponding to the lstclamps CA 
instance. Referring also to Fig. 115, compiler 8010 gleans information from simulation 
specification 9300 (see Fig. 88) and applies rules from simulation building table 2901 to the 
gleaned information to generate video and feedback tables which are in turn used to drive 
simulator 9816 (see Fig. 90). 

[00517] To this end, table 2901 includes a CA type column 2899, a "parameterization" 

column 2903 and a "modifications" column 2405. CA type column 2894 lists every CA type 
which may be selected via resource editor 9802. For the purposes of the present invention 
"SafeBulkHeadClampSet" CA type 8029 is included in column 2894. 
[00518] Referring to Figs. 88 and 115, parameterization column 2903 lists every 

possible parameterization which may be selected via resource editor 9802 which may alter 
and eliminate any aspect of a video or feedback table corresponding to the related CA type in 
column 2894. For CA type 8029, in the interest of brevity, only two parameterizations are 
listed in column 2903 including "clear box 9482d" parameterization 2907 and "clear box 
9480e" parameterization 2904. Many other parameterizations are contemplated. Column 
2905 includes one or more modifications to specification 9300 corresponding to each 
parameterization in column 2903. For example, modification 291 1 is to "delete table 9303" 
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when box 9482d is clear. Referring also to Fig. 85, box 9482d corresponds to box 9482a and 
hence is clear only when box 9482a is clear indicating that a particular CA instance does not 
require the second cylindicator (i.e. second cylindicator 9427 was not selected). Where 
second cylindicator 9427 is not selected, video table 9303 is not needed and therefore is 
deleted. 

[00519] As another example, modification 2913 is to "delete combination 9320" when 

box 9480e is clear. Referring also to Fig. 85, box 9480e corresponds to box 9480a and hence 
is clear only when box 9480a is clear indicating that a particular CA instance does not require 
the spring return valve 9423 (i.e. value 9423 was not selected). Where value 9423 is not 
selected, combination 9320 no longer is accurate and therefore is deleted. 
[00520] Referring now to Fig. 1 16, an exemplary compilation process performed by 

compiler 9810 is illustrated. At decision block 2915 compiler 8010 determines if an end 
sequence signal has been received from deconvolver 8002. If an end sequence signal has 
been received, control passes to block 2917 where compiler 8010 provides all of the 
parameterized video and feedback tables. If an end sequence signal has not been received, 
control passes to block 2919. 

[00521] At block 2919, compiler 8010 receives the simulation specification 

corresponding to the next request in chart 5830 to be compiled. In the present example, 
compiler 8010 receives simulation specification 9300 ( see Fig. 88) corresponding to CA 
instance lstclamps. Continuing, at block 2921 compiler 8010 gleans parameterization 
information from specification 9300. At block 2923, compiler 8010 accesses simulation 
building table 2901 and identifies CA type "SafeBulkHeadClampSet" 8029 and 
corresponding parameterizations and modifications. At block 2925 compiler 8010 
parameterizes tables in specification 9300 according to the modifications in table 2901 and 
then control passes back up to decision block 2915. 

[00522] Referring to Figs. 88, 90 and 116, after the end sequence signal is received at 

block 2915 and control passes to block 2917, compiler 8010 provides a complete set of 
simulation tables to simulator 9816 via bus 8442. 

[00523] At this point virtually all controls products have been generated for 

constructing, simulating and controlling the control system and control process specified in 
the control bar chart 5830 of Fig. 72. Referring also to Fig. 101, the control products include 
an execution code 2009, a PLC I/O table 201 1, HMI configuration/linking table 2027, 
diagnostics linking table 2751, a schematic diagram and a simulation table. 
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[00524] An engineer can use the control tools to simulate operation of the mechanical 

resources or to configure actual mechanical resources thereby building a machine line. In 
either case, after configuring a line (either virtually or in the real world), a PLC or a soft PLC 
(i.e., a PLC model run using software) can be used to control the mechanical resources and to 
generate diagnostic messages which indicate next events to occur. When an expected event 
does not occur, the diagnostic message indicates the event which did not occur to help an 
operator determine the cause of the failure. 
[00525] 5. Core Modeling System 

Referring to Figs. 72, 88, 90 and 101, after the execution code 2009 and I/O table 
201 1 have been provided to PLC 9814, each of HMI linking table 2027 and diagnostics 
linking table 2751 have been provided to HMI 8437 and a parameterized set of simulation 
tables (i.e. video and feedback tables) have been provided to CMS 9816, HMI 8427, PLC 
9814, CMS 9816, module 9818 and screen 9820 can be used to virtually simulate the process 
specified by bar chart 5830 and corresponding CA instances. To this end, PLC 9814 is linked 
to CMS 9816 via a two way bus 6901, CMS 9816 is linked to module 9818 via a two way 
bus 6903 and module 9181 is linked to screen 9820 via a bus 6905. 

[00526] To simulate the process of bar chart 5830, PLC 9814 runs the execution code 

stored therein under the direction of HMI workstation 8437. PLC outputs are provided to 
CMS 9816 via bus 6901. Referring also to Fig. 88, CMS 9816 accesses parameterized video 
tables and based on output combinations, selects one or more video clips to be played via 
screen 9820 to virtually present the process of chart 5830. Video clip commands are 
provided by CMS 9816 via bus 6903 to module 9818. Module 9818 accesses the video clips 
required by the received video clip request signals and plays the clips on screen 9820. 
[00527] As described above, in this embodiment module 9818 is capable of identifying 

specific events during the playing of video clips and providing feedback signal indicating the 
event. For example, module 9818 can recognize the end of a video clip and send one or more 
feedback signals to CMS 9816. When a feedback signal is received, CMS 9816 accesses a 
feedback table and identifies PLC input signals which correspond to the feedback event. For 
example, when a lstclamps extend video is completed, lstclamps II and lstclamps 12 PLC 
inputs should be changed to "1" and "0", respectively, (see 9304 in Fig. 88). 
[00528] CMS 9816 provides the feedback PLC input signals to PLC 9814 via bus 

6901. When the input signals are received, referring also to Fig. 101, controller 2001 
modifies I/O table 201 1 accordingly which affects operation of code 2009. 
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[00529] Referring still to Figs. 72, 88 and 90, in the alternative, it is contemplated that 

CMS 9816 may be capable of animating actual CAD images of mechanical resources in the 
manner prescribed by bar chart 5830. 

[00530] Although a relatively simple simulation system is described above wherein 

compilation of a simulation specification results in a PLC mapping table for effectively 
converting PLC I/O into video commands for module 9818, other simulation systems are 
contemplated which support other than a one-to-one conversion of I/O combinations to video 
clips. In this regard, it has been recognized that most mechanical resources do not respond in 
an ideal manner to requests to perform activities and that operation of mechanical resources 
in response to specific I/O combinations are not always identical for various reasons. As a 
simple example, consider a hydraulic clamp and an I/O combination which indicates that the 
clamp should be extended. Ideally, upon receiving an extend request the clamp immediately 
changes its position from retracted to extended. In reality, however, because the clamp has 
mechanical components, clamp extension is not instantaneous but rather requires a finite 
time. Thus, the mechanical nature of the clamp renders ideal operation impossible (i.e., 
instantaneous extension is impossible). 

[00531] An approximation of actual clamp operation can be facilitated by assuming a 

clamp requires an exemplary estimated amount of time to extend. For example, it may be 
assumed clamp extension requires five seconds. In this case a simulated video clip may be 
controlled such that a clamp extension appears to require five seconds to close. While a five 
second rule may more closely reflect reality than instantaneous closure, such a rule is, as 
indicated above, nothing more than another estimate of reality which may or may not be 
accurate. 

[00532] In most cases a single rule such as extension time will be inaccurate to some 

unspecified degree. Variance between operation in reality and an estimated operating rule 
can be attributed to a plethora of sources. For example, in most cases the mechanical 
resources associated with a CA may be configured using hardware manufactured by any of 
several different vendors. In the case of clamp extension, all other things being equal, clamp 
hardware from one vendor may extend in three seconds while another vendor's clamp 
hardware may require six and one-half seconds while still another vendor's hardware may 
extend in five seconds. Clearly, in this case, an estimate of five seconds for clamp extension 
would be inaccurate much of the time. 

[00533] As another example, variance may also be attributed to resource environment. 

For instance, a clamp which extends in five seconds in a 70 °F plant where the humidity level 
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is 20% may require nine seconds when the temperature is reduced to 0°F and 0% humidity 
and may require seven seconds where the temperature is 70 °F and the humidity is 60%. 
[00534] Still another exemplary variance source is temporally proximate operation. 

For instance, a clamp which is routinely and rapidly extended and retracted may require a 
shorter extension period than the same clamp if the clamp is infrequently extended and 
retracted. Other variance sources (e.g., wear and tear) are contemplated. 
[00535] While operating approximations may be sufficient in some simulation 

applications, such approximations are often insufficient. This is particularly true in complex 
simulation applications where two or more mechanical resources may cause components to 
travel within the same space at different times. Similarly, operating approximations are 
insufficient where process time is important for cost justification purposes. In these cases it 
is extremely important that, to the extent possible, operating characteristics of resources be 
modeled as precisely as possible. 

[00536] Furthermore, discrete event simulation which simply simulates event order 

and which does not reflect event duration is relatively useless for simulating fault or 
exception (i.e., process description) management. For instance, with a discrete event 
simulator, if a user simulates a faulty clamp extend sensor by disabling the sensor, the 
discrete event simulator simply simulates subsequent events in rapid succession until a "wait" 
state is achieved. In this case, because the subsequent events are rapidly simulated, very little 
can be gleaned from the simulation about how the PLC actually managed the faulty 
condition. 

[00537] It has been recognized that "relative time" simulation is a better alternative to 

discrete event simulation for the purpose of identifying fault management operation and 
capabilities. To this end, it is contemplated that a simulator includes a relative time clock 
(not illustrated) which, during simulation, maintains relative time periods of event execution. 
For example, if extension of one clamp type requires two minutes and extension of a second 
clamp type requires one minute, while the simulator may be programmed to compress event 
execution time, the period duration ratio remains the same such that, if simulation of the first 
clamp type is compressed to twenty seconds instead of two minutes, simulation of the second 
clamp type is compressed to ten seconds to maintain the 2-to-l ratio. Thus, mechanical 
resource operating variances corresponding to both event execution and fault maintenance 
must be specified for each mechanical resource. 
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[00538] Unfortunately it would be extremely difficult to specify all resource operating 

characteristics (e.g., stroke speed, temperature and humidity effects, etc.) within a CA. While 
this task is possible and is contemplated by another embodiment of this invention, a huge 
number of parameterizations and contingencies would have to be specified within the CA 
which would render the above described parameterization process daunting. For example, 
resource hardware, operating environment, recent temporal activities and so on would have to 
be specified for each resource during parameterization. In addition, to modify any one of 
these aspects a new CA would have to be instantiated, parameterized and compiled. Such 
complexity no doubt would render the entire system difficult to use. 
[00539] In addition to mechanical resource operation variance, other information 

corresponding to a process to be simulated must be specified. For example, in addition to 
interaction between mechanical resources and PLCs, other entities, referred to collectively 
herein as "third entities", typically interact with the mechanical resources and PLCs during a 
process and third entity characteristics need to be modeled. For instance, emergency or "E" 
stops are routinely provided along machine lines which consist of stop buttons, switches, or 
the like which can be activated to cut power off to line stations thereby rendering the stations 
safe for operator entry. E-stop/PLC interaction is typically limited to an activation signal sent 
to the PLC when an E-stop is activated. Nevertheless, E-stop activation clearly has a much 
greater affect on line operation than simply signaling a PLC. The E-stop affect has to be 
modeled to facilitate realistic simulation. 

[00540] As another instance, a PLC may provide a signal causing a shot pint to be fired 

into a position which locks two mechanical devices together until the pin is subsequently 
removed via PLC instruction. In this case, the shot pin has characteristics independent of 
PLC control which affect the overall process. For instance, even where the process fails for 
some reason or where an E-stop is used to halt the process, a locking shot pin which locks 
two devices together remains locked and that characteristic must be modeled. 
[00541] As still one other instance, many processes require operator intervention or 

cooperation. For example, a process may require a machine line operator to load components 
at a first station, subsequently lock-out, tag-out and enter a third station to check part 
orientation, un-tag and un-lock the third station and so on. Although these process steps are 
not controlled by a PLC, these steps affect process execution and therefore must be modeled 
to facilitate realistic process simulation. 

[00542] According to a second embodiment of the inventive simulation aspect, 

simulation information required for realistic simulation is divided into first and second 
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information sets including "control characteristics" and the combination of both 
"circumstantial characteristics" and third entity characteristics. Control characteristics are 
characteristics which, after CA parameterization, are identical for resources corresponding to 
the CA and are independent of other circumstantial considerations which affect request 
execution. For example, in the case of a SafeBulkHeadClampSet CA, control characteristics 
include the devices specified in the CA, resource requests and corresponding I/O 
combinations and feedback events and corresponding I/O combinations. From a controls 
perspective all of these characteristics of resources corresponding to a CA are identical. 
[00543] Circumstantial characteristics, as the name implies, are characteristics which 

may vary for a given CA resource and which affect request execution. Circumstantial 
characteristics may vary with the hardware used to configure a resource, resource 
environment, recent resource activities, etc. For example, in the case of a clamp, one 
circumstantial characteristic may be that extending speed is dependent upon environmental 
and other circumstantial conditions. For instance, extending speed may vary with humidity 
and/or temperature. Similarly, extending speed may depend on recent clamp activity. To this 
end, where a clamp has recently been stagnant for a period, extending speed may be slower 
than where a clamp has been active (i.e., extending and contracting). In addition 
circumstantial characteristics typically are related to hardware used to configure resources. 
Thus, hardware from one vendor often will have different extending speed characteristics 
than hardware from another vendor. 

[00544] As described above, third entity characteristics include characteristics which 

are related to system hardware, software and system operators which function, at least in part, 
independent of PLC commands. These characteristics include the existence of the third 
entities, how the third entities respond to PLC commands or interact with mechanical 
resources which are controlled by the PLC and so on. 

[00545] It has been recognized that because of the universal and fundamental nature of 

control characteristics, these characteristics can easily be specified within a CA simulation 
specification. Moreover, control characteristics can generally be gleaned from non- 
simulation information which must be specified for other CA purposes such as specifying 
characteristics required to generate execution code. 

[00546] It has also been recognized that a core modeling system (CMS) can be used to 

specify circumstantial characteristics of resources and to specify third entity characteristics, 
to combine circumstantial, control and third entity characteristics via various modeling 
algorithms and to, based on the combined characteristics , facilitate relatively realistic 
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simulation. Thus, resource characteristics which are essentially unchanging from a controls 
perspective are specified within the CA simulation specification and all other circumstantial 
and third entity characteristics which affect request execution are specified by the CMS 9816. 
[00547] Referring now to Figs. 90 and 1 17, an exemplary CMS 9816 which supports 

this second embodiment of the invention includes a CMS processor 2950, an interface 2948 
and a database 2951. Processor 2950 is linked to interface 2948 via a two way bus 2947 and 
to database 2951 via a two way bus 2949. Processor 2950 is a standard microprocessor 
which is capable of performing various functions as described in more detail below. 
[00548] Initially, database 2951 includes data structure templates (DSTs) 2974. After 

CMS 9816 imports control characteristics from simulation specifications the control 
characteristics are used to populate DTSs and generate separate instantiated data structure 
instances 2953 for each resource to be simulated. Data structure instantiation is described in 
more detail below. Referring still to Fig. 1 17, a separate DST 2974 is provided for each 
simulatable resource type which is included in any CA supported by ECDB 9810 ( see Fig. 
90). For example, referring to Figs. 84 and 85, CA 9000 includes six resources (i.e., two 
valves and four cylindicators). Herein it is assumed that CMS 9816 cannot simulate valve 
movement but can simulate clamp extension and retraction. Therefore, DSTs 2974 do not 
include a DST which models a valve but do include a DST which models a clamp. Because 
each of the four cylindicators in CA 9000 may be simulated with a similar video clip, only 
one DST 2974 is required to support all four cylindicators. 

[00549] Referring to Figs. 117 and 1 1 8, an exemplary instantiated data structure 2952 

is illustrated. While structure 2952 is already instantiated (i.e., control characteristics have 
already been included), the general configuration of an exemplary DST can be appreciated by 
examining structure 2952. In this preferred embodiment each DST includes a name field 
2970, a control characteristics field 2971 and a circumstantial characteristics field 2972. 
Name field 1970 and control characteristics field 2971 are initially blank. Upon importation 
of CA information, name field 2970 is filled with a specific device name. In Fig. 118 field 
2970 is already filled with device name "1st cylindicator clamp 2506A". 
[00550] Despite being initially blank, it is contemplated that field 2971 will have some 

structure which is designed to receive imported information. In the present example, 
referring again to Fig. 88 and 1 18, it is assumed field 2971 is configured to store a portion of 
a simulation specification corresponding to a single clamp resource. For example, referring 
also to Figs. 85 and 88, after parameterization, tables 9302 and 9304 correspond to the "1st 
cylindicator clamp 2506A" device and therefore, if field 2970 specifies 1st cylindicator clamp 
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2560A, upon import of CA information, field 2971 is populated with tables 9302 and 9304. 
Tables 9302 and 9304 are illustrated in field 2972. 

[00551] Referring still to Fig. 118, circumstantial characteristics field 2972 includes 

two sub-fields including a circumstantial variables field 2975 and a simulation rule set field 
2976. Field 2975 includes a list of variables correlated with variable values which 
correspond to information which effects request execution. For example, field 2975 may 
include a temperature variable, a humidity variable, a stroke speed variable during extension 
of a clamp, etc. 

[00552] Field 2976 includes simulation rules or modeling algorithms corresponding to 

requested resource activities. In essence, simulation rules are equations or algorithms which, 
when an activity is requested, determine how an activity would be executed in the real world 
and generate data useable by CMS processor 2950 to affect realistic simulation. For 
example, assume a PLC I/O combination is received by CMS 9816 requesting a retract clamp 
video clip. Simulation rule set 2976 may include a rule which specifies that at one 
temperature the video clip will be completed in five seconds and at a relatively cooler 
temperature the clip will be completed in seven seconds. Here it is contemplated that a 
simulation temperature is specified in circumstantial information sub-field 2975. Thus, 
referring also to Fig. 117, when a retract I/O combination is received, processor 2950 
accesses an appropriate rule from field 2976, identifies circumstantial information required 
by the rule, retrieves the circumstantial information from field 2975, applies the rule to the 
circumstantial information to generate a video clip speed signal and then controls video clip 
speed to facilitate realistic simulation. Many other simulation rule sets are contemplated. 
[00553] Referring again to Fig. 1 17, in addition to including a separate DST 2974 for 

each simulatable resource type included in a CA supported by ECDB 9810, data base 2951 
also includes a separate DST 2974 for each third entity which may be required to interact 
with PLC and affect process operation. The DSTs 2974 corresponding to third entities are 
different than the DSTs 2974 corresponding to simulatable resources in that the third entity 
DSTs 2974 include entity characteristics as well as software which models entity operation. 
Referring also to Fig. 121, an exemplary third entity DST 31 1 1 is illustrated which includes 
an entity name field 3113 and an entity model and characteristics field 3115. 
[00554] Upon compilation of sequenced requests and activities, CA requests and 

activities are gleaned to identify third entities which must be supported for simulation 
purposes. For example, where a CA has been instantiated which corresponds to a mechanical 
resource for firing a shot pin to lock two devices together, the simulation compiler recognizes 
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the simulation requirement that a third entity data structure corresponding to a shot pin be 
instantiated. 

[00555] Similarly, where an operator activity has been included in a control bar chart, 

upon compilation the simulation compiler identifies the requirement for an operator data 
structure to be instantiated. 

[00556] As with the resource DSTs described above it is contemplated that the third 

entity DSTs will include a separate DST for each third entity type. Referring to Fig. 121, 
upon compilation, when a third entity data structure is required, the compiler identifies the 
entity type, selects an appropriate DST 2974, populates the DST with an entity name in field 
3113 and more populate other information in field 3115 such as, in the case of an E-stop, 
information indicating how the data structure will interfere with PLC I/O. After compilation, 
the third entity data structures are used in conjunction with the resource data structure to 
facilitate simulation. 

[00557] During simulation it is contemplated that clock speed may be modified by a 

system operator to increase or decrease simulation speed while still maintaining relative event 
duration speeds. Thus, if first and second strokes initially require five and ten seconds, 
respectively, and the clock is slowed down such that the first stroke requires ten seconds, the 
second stroke would require twenty seconds thereby maintaining the relative durations of the 
strokes. In this manner relatively unintersecting simulation can be sped through and more 
interesting simulation can be slowed so that nuances can be identified. 
[00558] Referring again to Fig. 1 18, generally, a system user will standardize with 

specific hardware provided by specific vendors and therefore many simulation rule sets for a 
specific user can be set once for a particular resource and used routinely thereafter. In fact, it 
is contemplated that many if not all of the rule sets in field 2976 may be provided by a 
hardware manufacturer for installation. In addition, in regulated environments where 
temperature and humidity is maintained at constant levels some of the circumstantial 
variables in field 2975 may also be set once and used routinely thereafter. 
[00559] While many of the rule sets in fields 2976 may be provided by manufacturers 

of hardware, variables in field 2975 often will need to be specified and, in some cases, it may 
be advantageous to modify the simulation rule sets in field 2976. To this end, referring again 
to Fig. 1 17, it is contemplated that interface 2948 is equipped to enable a system user to 
access DSTs 2974 and/or separate data structures 2953 to modify circumstantial variables 
and/or rule sets in field 2975 and 2976, respectively. For instance, a temperature variable in 
field 2975 may be modified to modify a simulation environment. It is also contemplated that 
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interface 2948 may be used to globally modify certain circumstantial variables such as 
temperature and/or humidity, etc. for all DSTs and all data structures. Any interface known 
in the computing arts would suffice for these purposes. 

[00560] Referring again to Fig. 117, upon import of simulation control characteristics a 

separate data structure 2953 is instantiated for each simulatable resource. A complete 
example of how data structures 2953 are generated is helpful. 

[00561] To this end, referring again to Figs. 88 and 90, as described above, after CA 

parameterization and compiling (via compiler 9812), parameterized simulation specifications 
like specification 9300 result. Referring also to Fig. 85, herein it will be assumed all 
resources in logic specification 9002 have been selected via logic specification 9002 and 
therefore parameterized simulation specification 9300 includes eight tables including a 
separate video table (e.g. 9302) and a separate feedback table (e.g., 9304) corresponding to 
each of the four cylindicators. Moreover, it will be assumed PLC I/O terminals have been 
assigned to specific resources for providing I/O requests to resources and receiving I/O 
feedback signals from sensors. 

[00562] Referring to Figs. 88, 90, 1 17 and 1 19, at processor block 2980 processor 

2950 receives simulation specifications (e.g. 9300) from compiler 9812. At block 2981 
processor 2950 identifies a DST (e.g., 2952) for each simulatable resource which is included 
in each simulation specification and a DST for each third entity indicated in a simulation 
specification or in a sequenced bar chart. For example, as described above, simulation 
specification 9300 ( see Fig. 88) includes four (only two shown) simulatable resources (i.e., 
the clamps corresponding to the first through fourth cylindicators) and therefore processor 
2950 identifies four separate instances of the DST corresponding to a clamp, a separate clamp 
DST instance for each resource. 

[00563] Operation of CMS 9816 with respect to each simulatable resource and each 

third entity is similar and therefore, in the interest of simplifying this explanation, CMS 9816 
operation will only be described in the context of the first cylindicator clamp 2506A resource. 
[00564] With respect to the clamp 2506A resource, at block 2982, processor 2950 

places the resource name in name field 2970. In addition, at block 2982 processor 2950 
populates control characteristics field 2971 with video and feedback tables (i.e., tables 9302 
and 9304) corresponding to the clamp 2506A resource. Finally, at block 2983, processor 
2950 stores the instantiated data structure instance. After data structures for each simulatable 
resource in each imported simulation specification have been stored in database 2951, CMS 
9816 is equipped to support relatively realistic simulation. 
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[00565] It should be appreciated that after simulation information has been imported 

by CMS 9816, the CA has no other function with respect to simulation. In other words, the 
CA is a specifying data construct simulation is handled by CMS 9816. 
[00566] Referring now to Fig. 120, an exemplary simulation method is illustrated. 

Referring also to Figs. 90, 117 and 1 18, at process block 2984 processor 2950 receives a PLC 
I/O combination requesting a resource to perform an activity. In this example, it will be 
assumed the request is for 1st cylindicator clamp 2506A to retract (e.g., see again 
combination 9320 in Fig. 88). When the I/O combination request is received, at block 2985 
processor 2950 maps the combination into the video table associated with the PLC I/O 
terminals which generated the combination. In the present example, the combination is 
mapped into a video table (e.g., 9302 in Fig. 88) in control characteristics field 2971 at block 
2985. This mapping enables processor 2950 to identify a retract video clip as the clip to be 
generated. 

[00567] After a video clip to be generated is identified, at block 2986, processor 2950 

accesses simulation rule set 2976 to identify a rule which can be used to identify how 
circumstantial characteristics affect request execution. Also, at block 2986, processor 2950 
identifies circumstantial information required by the identified simulation rules and retrieves 
the requested information from circumstantial information sub-field 2975. 
[00568] Continuing, at block 2987 processor 2950 applies the identified simulation 

rules to the retrieved circumstantial information to identify simulation characteristics. At 
block 2988 processor 2950 accesses the feedback table (e.g., see 9304 in Fig. 88) stored in 
control characteristics field 2971 to determine if any events corresponding to a video clip 
should be indicated via feedback I/O to the PLC. If feedback I/O is to be supported, 
processor 9816 identifies the video clip event which will trigger the feedback signal(s). 
[00569] At block 2989 processor 2950 controls movie module 981 8 such that the video 

clip is advanced at a speed consistent with a speed corresponding to the circumstantial 
characteristic's affect on request execution. 

[00570] Next, at decision block 2990, if feedback events were to be monitored control 

passes to block 2991. In the alternative control passes back up to block 2984 and the next 
PLC I/O combination is received. At block 2991, simulation is monitored. At block 2977, 
when a feedback event (e.g., the end of a clip) is identified, control passes to block 2992 
where processor 2950 provides feedback I/O to the PLC. 

[00571] To simulate varying clamp extending speeds it is contemplated that CMS 9816 

can control frame advance speed of video clips displayed by module 9818. Thus, to simulate 
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slow clamp extension CMS 9816 simply slows down frame advance. With a CMS 9816 
which can control frame advance, CMS 9816 can identify the end of a stroke or device 
movement associated with feedback by monitoring frame advance. As in the above example, 
CMS 9816 provides feedback signals to the PLC to indicate monitored conditions. 
[00572] In another embodiment some circumstantial characteristics may be specified 

in a CA simulation specification. For example, consider the exemplary CA described above 
which specifies a single valve for supporting anywhere from one to four clamps. Also 
assume that the speed with which a valve can extend clamps is dependent upon the number of 
clamps which have to be extended (i.e., which are supported) by the valve. Thus, where the 
valve supports only one clamp, extension may be more rapid than where the valve supports 
four clamps. 

[00573] In this case, the number of clamps selected for instantiation in a CA clearly 

affects request execution in the real world and should be accounted for in virtual simulation. 
In other words, the number of clamps selected for instantiation in a CA is a circumstantial 
characteristic which should be included in the CMS modeling algorithms which correspond 
to the clamps. Despite being a circumstantial characteristic, it makes sense to include clamp 
quantity in the CA simulation specification as clamp quantity is specified during CA 
parameterization and can be gleaned from the CA. Thus, in this case, when CA simulation 
specifications are imported by CMS 9816, both control characteristics and at least one 
circumstantial characteristic are imported and stored in appropriate data structure fields. It is 
contemplated that other circumstantial characteristics may also be specified in a simulation 
specification. 

[00574] Thus, it should be appreciated that the simulation aspects of the inventive 

enterprise control system may be embodied in many different forms, the underlying inventive 
concept being that at least some information specified in CAS is exported from the CAS and 
used for generating simulation data structures. The data structures are then used by a CMS to 
drive a virtual video simulation as a function of PLC I/O combinations and to provide 
feedback to the PLC as simulation progresses. Hence, CAS are used for specifying and data 
structures are used for simulation. 

[00575] The invention has been described above with respect to preferred 

embodiments. Obviously, modifications and alterations will occur to others upon reading and 
understanding the preceding detailed description. It is intended that the invention be 
construed as including all such modifications and alterations in so far as they come within the 
scope of the following claims or equivalents thereof. For example, while some of the 
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specifications described above are described as being essentially complete in that little if any 
additional information is added to the specifications upon compiling to generate the control 
tools, it is contemplated that upon compiling information may be added to virtually any of the 
specifications, the important aspect of the invention being that most information required to 
specify the control tools is provided in the CAS. For instance, while the schematic 
specifications described above include compete schematics corresponding to all CDs in a CA, 
in another embodiment the schematic specification may only include information about CA 
I/O. In this case it is assumed that a schematic compiler would include schematics for each 
schematically displayable component of a CA, each schematic including I/O terminals. Upon 
compiling, each CA specifies the schematics required to illustrate the mechanical resources 
associated with the CA and also labels I/O terminals with CA I/O. Parameterization still 
occurs during CA specification and is reflected in the schematics chosen and I/O labeling 
during compilation. Once again, the important aspect is that information which is specified 
once and can be used for various specifying purposes is used several times to reduce the work 
required to configure all of the control tools. 
[00576] II. Previous Specification 

This invention relates to electronic programmable controllers for operating industrial 
equipment and visualizing the industrial environment being controlled. Electronic 
programmable controllers utilize a programming language to develop control programs to 
control industrial equipment. 

[00577] Programmable controllers are well-known systems for operating industrial 

equipment, such as assembly lines and machine tools, in accordance with a stored program. 
In these controllers, a stored program is executed to examine the condition of specific sensing 
devices on the controlled equipment, and to energize or de-energize selected operating 
devices on that equipment contingent upon the status of one or more of the examined sensing 
devices. The program not only manipulates single-bit input and output data representing the 
state of the sensing and operating devices, but also performs arithmetic operations, timing 
and counting functions, and more complex processing operations. 

[00578] One industry that extensively uses programmable controllers is the automotive 

industry. In the automotive industry, various automotive parts are conveyed along machine 
lines consisting of many consecutive workstations. Most workstations include at least one 
tool that performs some function to alter the characteristics of work pieces as they are 
delivered to the station. For example, an unfinished cast engine block that requires a plurality 
of holes, bores, and threads, as well as other metal-removing procedures, may be provided at 
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the beginning of a machine line that produces finished engine blocks. The machine line may 
consist of any number of different stations, each station performing a different procedure on 
the unfinished block. An indexer in the form of a transfer bar can be arranged to move each 
block from one station to the next following a completed process. Typically, at each station 
the block would be clamped prior to any metal-removing operation. 

[00579] In this type of system, a programmable controller would receive inputs from 

all of the various tools at all of the workstations and would provide activating output signals 
to synchronize machine operation. During metal-removing periods with the transfer bar out 
of the way, all of the tools would perform their functions. In between metal-removing 
periods during transfer periods, the tools would be parked, the clamps undamped, and the 
transfer bar would advance work pieces from one station to the next. 

[00580] Industrial controllers are frequently programmed in Ladder Logic (LL) where 

instructions are represented graphically by "contacts" and "coils" of virtual relays connected 
and arranged in ladder-like rungs across power rails. LL, with its input contacts and output 
coils, reflects the emphasis in industrial control on the processing of large amounts of input 
and output data. 

[00581] LL also reflects the fact that most industrial control is "real time"; that is, an 

ideal industrial controller behaves as if it were actually composed of multiple relays 
connected in parallel rungs to provide outputs in essentially instantaneous response to 
changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay- 
like structures, but instead simulate the parallel operation of the relays by means of a 
conventional Harvard or Von Neumann-type computer processor which executes instructions 
one at a time, sequentially. The practical appearance of parallel operation is obtained by 
employing extremely fast processors in the execution of the sequential control program. 
[00582] As each rung is executed, inputs represented by the contacts are read from 

memory (as obtained from inputs from the controlled process or the previous evaluation of 
coils of other rungs). These inputs are evaluated according to the logic reflected in the 
connection of the contacts into one or more branches within the rungs. Contacts in series 
across a rung represent boolean AND logic whereas contacts in different branches and thus in 
parallel across the rung represent boolean OR logic. 

[00583] Typically a single output coil at the end of each rung is set or reset. Based on 

the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a 
bit (which ultimately becomes an output to the industrial process or to another LL rung). 



-109- 



[00584] Once a given rung is evaluated the next rung is evaluated and so forth. In the 

simplest form of LL programming there are no jumps, i.e. all rungs are evaluated in a cycle or 
"scan" through the rungs. This is in contrast to conventional computer programming where 
branch and jump instructions cause later instructions or groups of instructions to be skipped, 
depending on the outcome of a test associated with those branch or jump instructions. 
[00585] While LL is well suited for controlling industrial processes like those in the 

automotive industry, LL programming is not an intuitive process and, therefore, requires 
highly skilled programmers. Where hundreds of machine tool movements must be precisely 
synchronized to provide a machining process, programming in LL is extremely time- 
consuming. The time and relative skill associated with LL programming together account for 
an appreciable percentage of overall costs associated with a control system. In addition, the 
final step in LL programming is typically a lengthy debugging and reworking step that further 
adds to overall system costs. 

[00586] One way to streamline any type of programming is to provide predefined 

language modules, expressed in a language such as LL, which can be used repetitively each 
time a specific function is required. Because of the similar types of tools and movements 
associated with different machine-line stations, industrial control would appear to be an ideal 
industry for such language modules. 

[00587] The predefined logic module approach works quite well for certain 

applications, like small parts-material handling or simple machining. The reason for this is 
that the LL required for these applications tends to be very simple. In small parts material 
handling applications the I/O count is low and the interfaces between modules are minimal. 
In fact, the mechanisms are often independent units, decoupled from neighboring 
mechanisms by part buffers such that no signals are required to be exchanged between 
modules. These "loosely coupled" systems lend themselves to "cut and paste" programming 
solutions. 

[00588] But the predefined, fixed logic module approach does not work well for other 

applications, for example metal-removing applications. There are two main reasons for this. 
First, there can be considerable variation in how components, such as sensors and actuators, 
combine to produce even simple mechanisms. Second, processes like metal removing 
normally requires tightly controlled interaction between many individual mechanisms. 
Exchanging signals called interlocks, between the control logic modules of the individual 
mechanism controls the interaction. The application of specific interlocks depends on 
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knowledge of the process and the overall control strategy, information not generally needed, 
or knowable, when the control logic for each mechanism is defined. 

[00589] For example, a drill is a typical metal-removing tool used in the automotive 

industry. In this example an ideal drill is mounted on a carriage that rides along a rail 
between two separate limiting positions on a linear axis, an advanced position and a returned 
position. Two limit switches, referred to herein as returned and advanced LSs, are positioned 
below the carriage and, when tripped, signal that the drill is in the returned and advanced 
positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a 
returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the 
advanced and returned positions are reached, respectively. In the ideal case, both LSs may be 
assumed to be wired in the same "normally opened" manner, so that electrically speaking 
they are open when released and closed when triggered. In this ideal case, where the physical 
characteristics of the switches are limited, a single LL logic rung can determine when the drill 
is in the returned position and another rung can determine when the drill is in the advanced 
position. 

[00590] Unfortunately, in reality, there are electrically two types of LSs, one LS type 

being wired normally opened and the other type wired normally closed. Furthermore, any LS 
can be mechanically installed in a tripped-when-activated configuration, or a released-when- 
activated configuration. All combinations of these types are used for various types of 
applications. Thus, application requirements may demand control logic capable of handling 
any configuration of LS types. 

[00591] Simple mathematics demonstrates that with two different electrical types of 

LSs and two mechanical configurations, there are sixteen possible configurations of a two- 
position linear slide. Consider the language modules required to implement position logic for 
all these configurations. To accommodate all sixteen-switch configurations, there could be 
sixteen different language modules, each containing fixed LL logic, and each named for the 
case it could handle. In this case, there would be duplicate logic under different names. 
Alternatively, four unique language modules could be provided, but then the user would have 
difficulty identifying which of the sixteen physical configurations that the four modules could 
handle. 

[00592] Clearly, even for a simple drill mounted on a two position linear slide, 

application variables make it difficult to provide a workable library of fixed language 
modules. Adding more switches to the linear slide only increases, to an unmanageable level, 
the number of language modules required in the library. 
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[00593] Moreover, the contents of a complete language module for a drill must also 

consider other variables. These variables include, for example, the number and type of 
actuators required; the type of spindle, if any; whether or not a bushing plate is required; what 
type of conveyor is used; whether or not the drill will include an operator panel to enable 
local control. If an operator panel is included, what type of controls (i.e. buttons, switches 
and indicator lights) are required, just to name a few. Each tool variable increases the 
required number of unique LL modules by more than a factor of two, which makes it difficult 
at best to provide an LL library module for each possible drill configuration. 
[00594] Taking into account the large number of different yet possible machine-line 

tools, each tool having its own set of variables, the task of providing an all-encompassing 
library of fixed language modules becomes impractical. Even if such a library could be 
fashioned, the task of choosing the correct module to control a given tool would probably be 
more difficult than programming the required LL logic from scratch. 
[00595] For these reasons, although attempts have been made at providing 

comprehensive libraries of fixed language modules, none has proven particularly successful 
and much LL programming is done from scratch. 

[00596] Manufacturing customers have long desired an integrated environment for 

generating an initial design schematic specifying a functional description of a manufacturing 
environment without the need for specifying product and manufacturing details. The system 
is provided with a designer studio that utilizes a common database of pre-architected modules 
to integrate a total system solution for the enterprise. The pieces of this system include 
design, simulation, implementation and maintenance information for both product and 
manufacturing. 

[00597] The foregoing problems are overcome in an illustrative embodiment of the 

invention in which a system for designing, simulating, implementing and maintaining an 
enterprise solution for an enterprise is disclosed. The system includes software that controls 
an enterprise. The software includes one or more components for controlling one or more 
aspects of an industrial environment with code that creates a database of components, each of 
the components containing control, diagnostic and resource information pertaining to 
enterprise resources utilized in the industrial environment. The software system also 
generates code that controls resources comprising cognitive and timing information that 
synchronizes events throughout the enterprise. The database of components includes code 
that updates the database to reflect changes in the enterprise that manage the design, 
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simulation, implementation and maintenance of a manufacturing enterprise utilizing the 
database of components. 

[00598] The system software defines and illustrates the electrical, pneumatic, 

hydraulic, logic, diagnostics, external behavior, controlled resources and safety elements of 
an enterprise control system. The elements of the control system are encapsulated in objects 
of an object-oriented framework within a control assembly. The control assembly is the 
fundamental building block for providing object-oriented control of the enterprise. 
[00599] A control assembly component is a deployable control subsystem that 

provides an interface using a common object model that is configurable. The control 
assembly exposes an interface of viewable elements. The logic associated with the interface 
allows the interface designer to query the control assembly to obtain the viewable elements 
and retrieve the properties of these viewable elements. 

[00600] A preferred embodiment of a system in accordance with the present invention 

is preferably practiced in the context of a personal computer such as an IBM, Apple 
Macintosh or UNIX based computer. A representative hardware environment is depicted in 
Figure 1 A, which illustrates a typical hardware configuration of a workstation in accordance 
with a preferred embodiment having a central processing unit 10, such as a microprocessor, 
and a number of other units interconnected via a system bus 12. The workstation shown in 
Figure 1 A includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an 
I/O adapter 18 for connecting peripheral devices such as disk storage units 20 to the bus 12, a 
user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a 
microphone 32, and/or other user interface devices such as a touch screen (not shown) to the 
bus 12, communication adapter 34 for connecting the workstation to a communication 
network (e.g., a data processing network) and a display adapter 36 for connecting the bus 12 
to a display device 38. The workstation typically has resident thereon an operating system 
such as the Microsoft Win/95 NT Operating System (OUTSTANDING) or UNIX 
OUTSTANDING. Those skilled in the art will appreciate that the present invention may 
also be implemented on platforms and operating systems other than those mentioned. 
[00601] A preferred embodiment is written using JAVA, C, and the C++ language and 

utilizes object oriented programming methodology. Object oriented programming (OOP) has 
become increasingly used to develop complex applications. As OOP moves toward the 
mainstream of software design and development, various software solutions will need to be 
adapted to make use of the benefits of OOP. A need exists for these principles of OOP to be 



-113- 



applied to a messaging interface of an electronic messaging system such that a set of OOP 
classes and objects for the messaging interface can be provided. 

[00602] OOP is a process of developing computer software using objects, including the 

steps of analyzing the problem, designing the system, and constructing the program. An 
object is a software package that contains both data and a collection of related structures and 
procedures. Since it contains both data and a collection of structures and procedures, it can 
be visualized as a self-sufficient component that does not require other additional structures, 
procedures or data to perform its specific task. OOP, therefore, views a computer program as 
a collection of largely autonomous components, called objects, each of which is responsible 
for a specific task. This concept of packaging data, structures, and procedures together in one 
component or module is called encapsulation. 

[00603] In general, OOP components are reusable software modules that present an 

interface that conforms to an object model and which are accessed at run- time through a 
component integration architecture. A component integration architecture is a set of 
architecture mechanisms which allow software modules in different process spaces to utilize 
each others capabilities or functions. This is generally done by assuming a common 
component object model on which to build the architecture. 

[00604] It is worthwhile to differentiate between an object and a class of objects at this 

point. An object is a single instance of the class of objects, which is often just called a class. 
A class of objects can be viewed as a blueprint, from which many objects can be formed. 
[00605] OOP allows the programmer to create an object that is a part of another object. 

For example, the object representing a piston engine is said to have a composition- 
relationship with the object representing a piston. In reality, a piston engine comprises a 
piston, valves and many other components; the fact that a piston is an element of a piston 
engine can be logically and semantically represented in OOP by two objects. 
[00606] OOP also allows creation of an object that "depends from" another object. If 

there are two objects, one representing a piston engine and the other representing a piston 
engine wherein the piston is made of ceramic, then the relationship between the two objects is 
not that of composition. A ceramic piston engine does not make up a piston engine. Rather it 
is merely one kind of piston engine that has one more limitation than the piston engine; its 
piston is made of ceramic. In this case, the object representing the ceramic piston engine is 
called a derived object, and it inherits all of the aspects of the object representing the piston 
engine and adds further limitation or detail to it. The object representing the ceramic piston 
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engine "depends from" the object representing the piston engine. The relationship between 
these objects is called inheritance. 

[00607] When the object or class representing the ceramic piston engine inherits all of 

the aspects of the objects representing the piston engine, it inherits the thermal characteristics 
of a standard piston defined in the piston engine class. However, the ceramic piston engine 
object overrides these ceramic specific thermal characteristics, which are typically different 
from those associated with a metal piston. It skips over the original and uses new functions 
related to ceramic pistons. Different kinds of piston engines will have different 
characteristics, but may have the same underlying functions associated with it (e.g., how 
many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these 
functions in any piston engine object, a programmer would call the same functions with the 
same names, but each type of piston engine may have different/overriding implementations 
of functions behind the same name. This ability to hide different implementations of a 
function behind the same name is called polymorphism and it greatly simplifies 
communication among objects. 

[00608] With the concepts of composition-relationship, encapsulation, inheritance and 

polymorphism, an object can represent just about anything in the real world. In fact, our 
logical perception of the reality is the only limit on determining the kinds of things that can 
become objects in object-oriented software. Some typical categories are as follows: 

• Objects can represent physical objects, such as automobiles in a traffic- flow 
simulation, electrical components in a circuit-design program, countries in an economics 
model, or aircraft in an air-traffic-control system. 

• Objects can represent elements of the computer-user environment such as windows, 
menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a table of the 
latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, and complex 
numbers, or points on the plane. 

[00609] With this enormous capability of an object to represent just about any logically 

separable matters, OOP allows the software developer to design and implement a computer 
program that is a model of some aspects of reality, whether that reality is a physical entity, a 
process, a system, or a composition of matter. Since the object can represent anything, the 
software developer can create an object which can be used as a component in a larger 
software project in the future. 
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[00610] If 90% of a new OOP software program consists of proven, existing 

components made from preexisting reusable objects, then only the remaining 10% of the new 
software project has to be written and tested from scratch. Since 90% already came from an 
inventory of extensively tested reusable objects, the potential domain from which an error 
could originate is 10% of the program. As a result, OOP enables software developers to build 
objects out of other, previously built, objects. 

[0061 1] This process closely resembles complex machinery being built out of 

assemblies and sub-assemblies. OOP technology, therefore, makes software engineering 
more like hardware engineering in that software is built from existing components, which are 
available to the developer as objects. All this adds up to an improved quality of the software 
as well as an increased speed of its development. 

[00612] Programming languages are beginning to fully support the OOP principles, 

such as encapsulation, inheritance, polymorphism, and composition-relationship. With the 
advent of the C++ language, many commercial software developers have embraced OOP. 
C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is 
suitable for both commercial- application and systems-programming projects. For now, C++ 
appears to be the most popular choice among many OOP programmers, but there is a host of 
other OOP languages, such as Smalltalk, common lisp object system (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more traditional popular computer 
programming languages such as Pascal. 

[00613] The benefits of object classes can be summarized, as follows: 

• Objects and their corresponding classes break down complex programming problems 
into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of data into small, 
independent objects that can communicate with each other. Encapsulation protects the data 
in an object from accidental damage, but allows other objects to interact with that data by 
calling the object=s member functions and structures. 

• Subclassing and inheritance make it possible to extend and modify objects through 
deriving new kinds of objects from the standard classes available in the system. Thus, new 
capabilities are created without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for different programmers to 
mix and match characteristics of many different classes and create specialized objects that 
can still work with related objects in predictable ways. 

Class hierarchies and containment hierarchies provide a flexible mechanism for 
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modeling real-world objects and the relationships among them. 

Libraries of reusable classes are useful in many situations, but they also have some 
limitations. For example: 

• Complexity. In a complex system, the class hierarchies for related classes can become 
extremely confusing, with many dozens or even hundreds of classes. 

• Flow of control. A program written with the aid of class libraries is still responsible 
for the flow of control (i.e., it must control the interactions among all the objects created from 
a particular library). The programmer has to decide which functions to call at what times for 
which kinds of objects. 

• Duplication of effort. Although class libraries allow programmers to use and reuse 
many small pieces of code, each programmer puts those pieces together in a different way. 
Two different programmers can use the same set of class libraries to write two programs that 
do exactly the same thing but whose internal structure (i.e., design) may be quite different, 
depending on hundreds of small decisions each programmer makes along the way. 
Inevitably, similar pieces of code end up doing similar things in slightly different ways and 
do not work as well together as they should. 

[00614] Class libraries are very flexible. As programs grow more complex, more 

programmers are forced to reinvent basic solutions to basic problems over and over again. A 
relatively new extension of the class library concept is to have a framework of class libraries. 
This framework is more complex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major mechanisms that implement the 
common requirements and design in a specific application domain. They were first 
developed to free application programmers from the chores involved in displaying menus, 
windows, dialog boxes, and other standard user interface elements for personal computers. 
[0061 5] Frameworks also represent a change in the way programmers think about the 

interaction between the code they write and code written by others. In the early days of 
procedural programming, the programmer called libraries provided by the operating system 
to perform certain tasks, but basically the program executed down the page from start to 
finish, and the programmer was solely responsible for the flow of control. This was 
appropriate for printing out paychecks, calculating a mathematical table, or solving other 
problems with a program that executed in just one way. 

[00616] The development of graphical user interfaces began to turn this procedural 

programming arrangement inside out. These interfaces allow the user, rather than program 
logic, to drive the program and decide when certain actions should be performed. Today, 
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most personal computer software accomplishes this by means of an event loop that monitors 
the mouse, keyboard, and other sources of external events and calls the appropriate parts of 
the programmer's code according to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, a program is divided into 
separate pieces that are called at unpredictable times and in an unpredictable order. By 
relinquishing control in this way to users, the developer creates a program that is much easier 
to use. Nevertheless, individual pieces of the program written by the developer still call 
libraries provided by the operating system to accomplish certain tasks, and the programmer 
must still determine the flow of control within each piece after it's called by the event loop. 
Application code still "sits on top of the system. 

[00617] Even event loop programs require programmers to write a lot of code that 

should not need to be written separately for every application. The concept of an application 
framework carries the event loop concept further. Instead of dealing with all the nuts and 
bolts of constructing basic menus, windows, and dialog boxes and then making these things 
all work together, programmers using application frameworks start with working application 
code and basic user interface elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework with the specific capabilities of 
the intended application. 

[00618] Application frameworks reduce the total amount of code that a programmer 

has to write from scratch. However, because the framework is really a generic application 
that displays windows, supports copy and paste, and so on, the programmer can also 
relinquish control to a greater degree than event loop programs permit. The framework code 
takes care of almost all event handling and flow of control. The programmer's code is called 
only when the framework needs it (e.g., to create or manipulate a proprietary data structure). 
[00619] A programmer writing a framework program not only relinquishes control to 

the user (as is also true for event loop programs), but also relinquishes the detailed flow of 
control within the program to the framework. This approach allows the creation of more 
complex systems that work together in interesting ways, as opposed to isolated programs, 
having custom code, being created over and over again for similar problems. 
[00620] Thus, as is explained above, a framework basically is a collection of 

cooperating classes that make up a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g., for menus and windows). 
Programmers use it by inheriting some of that default behavior and overriding other behavior 
so that the framework calls application code at the appropriate times. 
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[00621] There are three main differences between frameworks and class libraries: 

Behavior versus protocol Class libraries are essentially collections of behaviors that 
you can call when you want those individual behaviors in your program. A framework on the 
other hand, provides not only behavior but also the protocol or set of rules that govern the 
ways in which behaviors can be combined, including rules for what a programmer is 
supposed to provide versus what the framework provides. 

• Call versus override. With a class library, the class member is used to instantiate 
objects and call their member functions. It is possible to instantiate and call objects in the 
same way with a framework (i.e., to treat the framework as a class library), but to take full 
advantage of a framework=s reusable design, a programmer typically writes code that 
overrides and is called by the framework. The framework manages the flow of control 
among its objects. Writing a program involves dividing responsibilities among the various 
pieces of software that are called by the framework rather than specifying how the different 
pieces should work together. 

• Implementation versus design. With class libraries, programmers reuse only 
implementations, whereas with frameworks, they reuse design. A framework embodies the 
way a family of related programs or pieces of software work. It represents a generic design 
solution that can be adapted to a variety of specific problems in a given domain. For 
example, a single framework can embody the way a user interface works, even though two 
different user interfaces created with the same framework might solve quite different 
interface problems. 

[00622] Thus, through the development of frameworks for solutions to various 

problems and programming tasks, significant reductions in the design and development effort 
for software can be achieved. HyperText Markup Language (HTML) is utilized to 
implement documents on the Internet together with a general-purpose secure communication 
protocol for a transport medium between the client and the merchant. HTML is a simple data 
format used to create HyperText documents that are portable from one platform to another. 
HTML documents are Standard Generalized Markup Language (SGML) documents with 
generic semantics that are appropriate for representing information from a wide range of 
domains. HTML has been in use by the World-Wide Web global information initiative since 
1990. HTML is an application of ISO Standard 8879:1986 Information Processing Text and 
Office Systems; SGML. 

[00623] To date, Web development tools have been limited in their ability to create 

dynamic Web applications which span from client to server and interoperate with existing 
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computing resources. Until recently, HTML has been the dominant technology used in 
development of Web-based solutions. However, HTML has proven to be inadequate in the 
following areas: 

• Poor performance; 

• Restricted user interface capabilities; 

• Can only produce static Web pages; 

• Lack of interoperability with existing applications and data; and 

• Inability to scale. 

[00624] Sun Microsystem's Java language solves many of the client-side problems by: 

• Improving performance on the client side; 

• Enabling the creation of dynamic, real-time Web applications; and 

• Providing the ability to create a wide variety of user interface components. 
[00625] With Java, developers can create robust User Interface (UI) components. 
Custom "widgets" (e.g. real-time stock tickers, animated icons, etc.) can be created, and 
client-side performance is improved. Unlike HTML, Java supports the notion of client-side 
validation, offloading appropriate processing onto the client for improved performance. 
Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI 
components, dynamic Web pages can also be created. 

[00626] Sun's Java language has emerged as an industry-recognized language for 

"programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, 
interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, 
dynamic, buzzword-compliant, general-purpose programming language. Java supports 
programming for the Internet in the form of platform-independent Java applets." Java applets 
are small, specialized applications that comply with Sun's Java Application Programming 
Interface (API) allowing developers to add "interactive content" to Web documents (e.g. 
simple animations, page adornments, basic games, etc.). Applets execute within a Java- 
compatible browser (e.g. Netscape Navigator) by copying code from the server to client. 
From a language standpoint, Java's core feature set is based on C++. Sun's Java literature 
states that Java is basically "C++, with extensions from Objective C for more dynamic 
method resolution." 

[00627] Another technology that provides similar function to JAVA is provided by 

Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to 
build dynamic content for the Internet and personal computers. ActiveX includes tools for 
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developing animation, 3D virtual reality, video and other multimedia content. The tools use 
Internet standards, work on multiple platforms, and are being supported by over 100 
companies. The group's building blocks are called ActiveX Controls, small, fast components 
that enable developers to embed parts of software in HyperText markup language (HTML) 
pages. ActiveX Controls work with a variety of programming languages including Microsoft 
Visual C++, Borland Delphi, Microsoft Visual Basic programming system and J++. ActiveX 
Technologies also includes ActiveX Server Framework, allowing developers to create server 
applications. One of ordinary skill in the art will readily recognize that ActiveX could be 
substituted for JAVA without undue experimentation to practice the invention. 
[00628] A ladder logic editor in accordance with a preferred embodiment allows a user 

to program and display a PLC's ladder program as illustrated in Figure IB. The program 
utilized is the RSLogix program manufactured and sold by the assignee of the subject patent. 
The programming tool provides a graphical user interface to facilitate rapid prototype and 
production of programs for execution in a PLC. Information is organized in rungs of 
sequential instructions organized in the shape of a ladder (ladder logic). The tool allows an 
operator to determine if a particular hardware entity is in a particular state and thereby allows 
the operator to exercise complete control over the environment. The RSLogix program tool 
supports traditional ladder logic and nontraditional control languages such as C, C++ and 
Java. It takes advantage of a current and future pool of developing control programmers and 
supports a large base of legacy applications. The emphasis of this tool is to improve a 
programmer's productivity in entering control code. 

[00629] Although tools for programming a particular PLC to perform a particular task 

utilizing ladder logic exist, an integrated solution for designing, simulating, implementing 
and maintaining both product and manufacturing information across an enterprise has not 
existed until now. An enterprise wide solution is important to achieve important customer 
goals such as reducing commissioning time by allowing validation of the design before 
investing significant resources in implementing a design that may not address customer 
requirements. A preferred embodiment also provides consistent information across the 
enterprise without requiring redundant information. A single database is employed to capture 
and maintain design, simulation, implementation and maintenance information concerning 
the enterprise wide solution. The single database also facilitates consistent design and 
implementation details since changes in the product and process are stored as changes to the 
control are effected. 
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[00630] Another customer goal is to reduce downtime. This goal is addressed in 

accordance with a preferred embodiment by the architecture of the system. In accordance 
with a preferred embodiment, each component is designed with data and logic associated 
with various pieces of information that are critical to the operation of the component and the 
system. One set of information that is designed into each component is the logic and data for 
diagnosing problems with the component. Thus as models of the enterprise are built utilizing 
these components, the diagnostic system is automatically constructed based on carefully 
thought-out information for each of the components. Thus, as a sensor level measuring 
proper performance levels falls below an approved threshold, information about the particular 
component and the level is available with non-ambiguous data that can be communicated 
back to the operator to solve the problem. 

[00631] Today, major manufacturers are digitally integrating their design, simulation, 

implementation and maintenance manually and also integrating their processes and the 
processes of their suppliers. They are being driven to a solution in accordance with a 
preferred embodiment because design and manufacturing processes of major manufacturers 
are complex and the scale of their operations is enormous. Complex, large scale integration 
requires that all design, simulation, implementation and maintenance information must be 
accessible digitally across an enterprise in a common format. Each enterprise design domain 
(e.g., part, machine, control, and diagnostic) must be modeled in a computer representation 
containing syntax (format of the domain representation) and semantics (meaning of the 
domain representation). Finally, an integrated data model in accordance with a preferred 
embodiment must be adhered to by the entire enterprise to establish mappings between the 
domains and their respective representations. The resultant solution eliminates the barriers 
that traditionally exist between the design and manufacturing domains. 
[00632] Figure 2 illustrates an enterprise solution in accordance with a preferred 

embodiment. In today's environment a body engineer designs a door assembly based on 
experience of parts, structural knowledge and welding information. This information is given 
to a machine or tool engineer to design a detailed process and tools for manufacturing the 
door based on other experience and existing manufacturing information. Then, the control 
engineer must design the sensor / actuator relationships to implement the manufacture of the 
door in an automated environment based on experience. Timing diagrams, causal 
relationships, a Human Machine Interface (HMI), input / output tables, safety and diagnostic 
information must be integrated into the design after the fact and control logic must be 
generated to execute on the PLCs to implement the manufacturing processes. Then the 
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control environment including clamps, hydraulics, electrical, robots and transport systems 
must be integrated with the PLC to begin testing the feasibility of the architecture. Resultant 
changes and additional diagnostic information are cycled through as time marches on. 
Finally, the process engineer translates management numbers for finished goods into a high- 
level process of actions and resources based on acquired experience and provides raw 
materials and goals to drive the manufacturing process. Currently, without the subject 
invention, this process can literally take years. 

[00633] Enterprise wide controls in accordance with a preferred embodiment are 

necessary to organize and manage the increasing amount of information necessary to 
facilitate effective control of machines, processes and products. Management of this 
information includes validation statistics for the manufacturing enterprise, diagnostics and an 
organizational structure that avoids redundancies to avoid storage and execution 
inefficiencies. Feedback of control information into the design system is also critical to 
maintain a current view of the enterprise at all times and to synchronize information so that 
all engineers are literally singing out of the same hymnal. 

[00634] Enterprise wide controls construct a control system within an integrated, 

enterprise-wide model that reuses control assemblies from existing subscription libraries and 
linkages between products, processes, machine and control models. Controls, diagnostics 
and HMI code from the control system model database is systematic with full coverage 
diagnostics from the start of the process to completion. The code is always consistent with 
product, process, machine and control models. The enterprise wide control system generates 
code that is utilized to animate simulation and subsequent production displays with a 
graphical depiction at various levels of hierarchical detail of the enterprise. An operator can 
zoom in to observe particular areas based on information from the enterprise to control large 
parts of the enterprise from a central control station. 

[00635] An Enterprise Control Database (ECDB) acts as a single repository of 

enterprise information containing instantaneous access to engineering bill-of-material 
(EBOM) data for parts and assembly of parts as well as maintaining manufacturing bill-of- 
material (MBOM) which tracks the finished goods inventory as it is built. Factory service 
records are also captured and stored in the database as they occur. Control assemblies and 
control components are also stored in the ECDB. Diagnostic assemblies and diagnostic 
components are also stored with the control system configuration (processor, racks, networks 
and wiring diagrams). 
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[00636] A control component in accordance with a preferred embodiment is a machine 

part that either accepts inputs from the control system and / or generates outputs to the control 
system. A control assembly (descriptive class) is a configuration of control components and 
the defined set of states the control component can attain. The control assembly generates 
additional machine resource requirements and requests to the mechanical design system. A 
schematic of each control assembly is stored in the ECDB. 

[00637] A control assembly is also responsible for performing one or more actions 

defined as a discrete action class. For example, a class action may be an input signal that 
requests an action in an external word, or an input signal that confirms completion of a 
particular task. A class action in accordance with a preferred embodiment can appear as a bar 
on a barchart. A class input, often referred to by old-time control engineers as a digital input 
or DI could be an input signal indicative of a state in the enterprise. 

[00638] For example, when a heater reaches a threshold temperature, the process can 

proceed. Other examples include emergency stop, part present or a mode switch. Typically, 
class inputs are utilized as safeties, interlocks, cycle enablers or diagnostic inputs. A class 
output, digital output (DO) is an output signal to the enterprise to signal information. For 
example, turning on a cycle complete light. These entities readily lend themselves to 
implementation in an object-oriented abstraction as realizable classes for use in instantiating 
object instances of the classes. Examples of realizable classes in accordance with a preferred 
embodiment include PartPresent, ControlRobot, DumpSet, PinSet and 
SafeBulkHeadClampSet. 

[00639] Figure 3 illustrates a database entry for a SafeBulkHeadClampSet in 

accordance with a preferred embodiment. Each of the control valves, cylinders and other 
clamp information is stored in a single record completely defining the clamp and its 
characteristics to enable it to open and close on a target assembly effectively and safely. In 
addition, the database keeps track of how many catalog entries have incorporated this 
physical component into their design. 

[00640] A diagnostic component in accordance with a preferred embodiment is an 

electrical, mechanical or pneumatic component that has no direct connection to the control 
system and is architected into the component for diagnostic purposes. 
[00641] A diagnostic assembly (descriptive class) is a configuration of control 

components and diagnostic component in which the configuration is determined by the causal 
relationships that are useful for diagnostic purposes. Additional machine resource 
requirements may be required to generate requests to the mechanical design system. 
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[00642] Figure 4 is a block diagram of the enterprise system in accordance with a 

preferred embodiment. A CATIA design station 400 utilizes a CNEXT interface to transmit 
design information, activities (process steps) and resources (a description of the tooling 
machine) to the Enterprise Database (ECDB) 410. The design information is a picture, for 
example a door welding station, with robot welders, clamps, a PLC and a transport 
mechanism. The ECDB receives information from the CATIA CNEXT interface defining 
activities and resources that will be necessary to build the station. 
[00643] The ECDB integrates information from the CATIA CAD package 400, 

Designer Studio 430, code generation 440, final code 470 and the causal model subsystem 
450. The activities and information that come from the CATIA interface 400 are created by a 
mechanical tool designer and they omit key information that comes from the control designer. 
[00644] The Designer Studio 430 completes the activity and resource information in 

the ECDB 410 utilizing a graphical user interface that is C++ based Java code. The key 
organizing concept throughout an enterprise system in accordance with a preferred 
embodiment is CONTROL ASSEMBLY. Control assembly refers to utilizing a component 
based software assembly just as hardware designers utilize chip assemblies in hardware 
design and manufacture. A template type building block architecture is enabled for designing 
and managing enterprises. Software and hardware components are cataloged in the ECDB 
410 for maximal reuse of the components. The ECDB 410 is a relational database 
implemented in a Microsoft Access product in accordance with a preferred embodiment. One 
of ordinary skill in the art will readily comprehend that other databases (relational or 
network) could readily be substituted without undue experimentation. 

[00645] Once the database is populated, then information from the database is utilized 

to construct a code generation data structure 440 in a tree format as described later in detail. 
The database is also utilized to create the causal model 450. The causal model 450 is utilized 
to enable system diagnostics. The causal model is a LISP knowledge base. 
[00646] The causal model 450 and the code generation data structure 440 is utilized as 

input for the PanelView Editor to automatically generate the operator's interface. Old code 
modified to work with new interface. The PanelView Editor also generates control code in 
the form of ladder logic. The causal model 450 generates diagnostic ladder logic that is 
mixed with the control code from the code generation 440 to create the final code 470 for 
controlling and monitoring the enterprise. The ladder logic is downloaded to the PLC 472 for 
controlling the enterprise. 
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[00647] The relay ladder logic code for control and diagnostics are merged by 

multiplexor code. The PanelView Editor generates code that enables the user interface to 
display graphical depictions of what is happening in the process and also to display 
diagnostic output. 

[00648] The ECDB is also used by the RSWire schematic processor 480 to create 

schematic depictions of the sensor environment and transmit the schematic results back to the 
CNEXT system in CATIA where the tool design was also performed. This architecture, in 
accordance with a preferred embodiment, facilitates the location of changes in the processing 
efficiently which streamlines location of modification locations in the stations and control 
logic downstream. 

[00649] The output from the ECDB is also provided to a schematic detailing package 

(RSWire) which enables a control engineer to decide where each of the clamps on a welding 
machine should be and locates valves, pneumatic piping etc. on the schematic detailing. A 
control engineer can place the cylinders and the schematic is generated from this information 
for wiring, piping and/or HVAC layout. Components are predesigned that enable design of 
an enterprise wide control system in accordance with a preferred embodiment of the 
invention. Control assemblies are merely objects encapsulating data and functions for 
performing standard control functions. Another set of macros are architected in accordance 
with a preferred embodiment for wiring diagrams that are componentized. 
[00650] What we do for simulation is to load the PLC code into a PLC simulator 

SOFTLOGIX 5 (A/B product). This is utilized to drive a CAD simulator. The PLC 
Simulator & CAD Simulator utilize information from the CATIA database and the ECDB in 
accordance with a preferred embodiment. Then, when the code has been debugged, it is 
downloaded to the PLC 472 for production testing and ultimately running the enterprise. 
[00651] The final schematics generated by the schematic tool 480 are ultimately sent 

back to CATIA 400 utilizing the standard CNEXT interface. This feedback mechanism is 
necessary to synchronize the CATIA database with the ECDB 410. This feedback 
mechanism also facilitates the addition of geometry to the original CAD drawings. 
[00652] The database design of the ECDB includes tables that map activities into 

information appearing in the tables that is imported from the existing CATIA drawings. The 
resource import table is called Structural Components. It is implemented in accordance with 
a preferred embodiment in an ACCESS database with a record of the following structure: 
U:~lVCM980330a.mdb Monday, March 30, 1998 

Table: StructuralComponents 
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[00653] 



Properties 



Date Created: 
Last Updated: 
RecordCount: 



3/6/98 11:18:49 AM 
3/30/98 2:14:37 PM 
56 



Def. Updatable: True 
OrderByOn: True 



[00654] 



Columns 



Name Type 

StructuralComponentID 
AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Ordinal Position: 
Required: 
Source Field: 
Source Table: 



Size 

Number (Long) 4 
False 

Fixed Size, Auto-Increment 

General 

False 

Default 

Default 

1 

False 

StructuralComponentID 
StructuralComponents 



ExtlDText 

AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Description: 
DisplayControl: 
Ordinal Position 
Required: 
Source Field: 
Source Table: 



255 

False 

Variable Length 
General 
False 
Default 
8268 

unique id for this spatial component 
Text Box 
2 

False 
ExtID 

StructuralComponents 



component 



Label Text 

AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Description: 



50 

False 

Variable Length 

General 

False 

Default 

1620 

label to show on graphic renditions of this 



DisplayControl: Text Box 
Ordinal Position: 3 
Required: 
Source Field: 
Source Table: 



False 
Label 

StructuralComponents 



Class Text 

AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 



50 

False 

Variable Length 
General 
False 
Default 
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ColumnWidth: 
Description: 



1545 

class of spatial components to which this instance 
belongs - determines what types of control 
components can be in this spatial component 



DisplayControl: Text Box 

Ordinal Position: 4 

Required: False 

Source Field: Class 

Source Table: StructuralComponents 



WorkCelllD Number (Long) 



AllowZeroLength: 
Attributes: 
Bound Column: 
Caption: 
Collating Order: 
Column Count: 
Column Heads: 
Column Widths: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Decimal Places: 
Default Value: 
Description: 

DisplayControl: 
Limit To List: 
List Rows: 
List Width: 
Ordinal Position: 
Required: 
Row Source Type: 
Row Source: 

Source Field: 
Source Table: 

PartOf Text 

AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Description: 



False 
Fixed Size 
1 

WorkCell 

General 

1 

False 

1440 

False 

Default 

1140 

Auto 

0 

workcell that this component is part of - either this 

field or the next one is mandatory 

Combo Box 

False 

8 

1440twip 
5 

False 

Table/Query 

SELECT DISTINCTROW [WorkCell]. [WorkCelllD] 

FROM [WorkCell]; 

WorkCelllD 

StructuralComponents 

255 

False 

Variable Length 
General 
False 
Default 



5985 

other spatial component that this component is 
part of - if this field is 0, it is a top level component 
DisplayControl: Text Box 
Ordinal Position: 6 
Required: True 
Source Field: PartOf 
Source Table: StructuralComponents 



Comment Memo 

AllowZeroLength: 



False 
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Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Ordinal Position: 
Required: 
Source Field: 
Source Table: 



Variable Length 

General 

False 

Default 

Default 

7 

False 
Comment 

StructuralComponents 



Relationships 

Reference26 



StructuralComponents Control Assemblylnstance 

StructuralComponentID StructuralComponentID 



Attributes: 
Attributes: 

Reference27 



Not Enforced 
One-To-Many 



StructuralComponents PCCInstanceElements 

StructuralComponentID StructuralComponentsID 



Attributes: 
Attributes: 



Table Indexes 



Name 

PrimaryKey 

Clustered: 

Distinct Count: 

Foreign: 

Ignore Nulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

SpaceComponentID 
Clustered: 
Distinct Count: 
Foreign: 
Ignore Nulls: 
Name: 
Primary: 
Required: 
Unique: 
Fields: 



Not Enforced 
One-To-Many 



Number of Fields 
1 

False 
56 

False 
False 

PrimaryKey 
True 
True 
True 

StructuralComponentID, Ascending 
1 

False 
56 

False 
False 

SpaceComponentID 

False 

False 

False 

ExtID, Ascending 



StructuralComponentsID 



1 
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Clustered: 
Distinct Count: 
Foreign: 
Ignore Nulls: 
Name: 
Primary: 
Required: 
Unique: 
Fields: 
WorkCelllD 

Clustered: 
Distinct Count: 
Foreign: 
Ignore Nulls: 
Name: 
Primary: 
Required: 
Unique: 
Fields: 

User Permissions 

ACR 
admin 
ALA 
ALA2 
BJB 
CPI 

Group Permissions 

Admins 
Guests 
LETTERS 
MODIFY 
READ ONLY 
REPAIR 
Users 

Items that utilize the control assembly catalog have the following structure: 
Table: ControlAssemblyCatalog 

Properties 

Date Created: 10/22/97 1 :25:38 PM Def. Updatable: 
True 

Description: CUnit stands for "control unit" Last Updated: 3/30/98 1 :45:32 
PM 

These are the generic types of 
assemblies that are relevant for 
control. The description only 
specifies how to interact with 
assembly from a control standpoint; 

it doesn't say how the instance will 

be used. 



False 
56 

False 
False 

StructuralComponentsID 

False 

False 

False 

StructuralComponentID, Ascending 
1 

False 
1 

False 
False 

WorkCelllD 
False 
False 
False 

WorkCelllD, Ascending 
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OrderByOn: False 
Columns 



RecordCount: 



Name Type Size 

Control AssemblyCatalog ID Number (Long) 4 

AllowZeroLength: False 

Attributes: Fixed Size, Auto-Increment 

Collating Order: General 

ColumnHidden: False 

ColumnOrder: Default 

ColumnWidth: 1092 

Description: unique idenitifier for the component structure 

Ordinal Position: 1 

Required: False 

Source Field: ControlAssemblyCatalogID 

Source Table: ControlAssemblyCatalog 

Label Text 25 

AllowZeroLength: False 

Attributes: Variable Length 

Collating Order: General I 

ColumnHidden: False 

ColumnOrder: Default 

ColumnWidth: Default 

Description: human readable name for the component structure 

DisplayControl: Text Box 

Ordinal Position: 2 

Required: False 

Source Field: Label 

Source Table: ControlAssemblyCatalog 

DecompositionType Text 50 

AllowZeroLength: False 

Attributes: ~ Variable Length 

Bound Column: 1 

Collating Order: General 

Column Count: 1 

Column Heads: False 

Column Widths: 1440 

ColumnHidden: False 

ColumnOrder: Default 

ColumnWidth: 1944 

Description: whether this assembly can be broken down into 

discrete components or whether it is a single 
object like a robot or a PanelView. 

DisplayControl: Combo Box 

Limit To List: False 

List Rows: 8 

List Width: 1440twip 

Ordinal Position: 3 

Required: False 

Row Source Type: Value List 

Row Source: ,, Virtual ,, ; ,, Physical"; ,, Programmable n 

Source Field: DecompositionType 
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Source Table: 



ControlAssemblyCatalog 



TemplateType Text 

AllowZeroLength: 
Attributes: 
Collating Order: 
ColumnHidden: 
ColumnOrder: 
ColumnWidth: 
Description: 
DisplayControl: 
Ordinal Position: 
Required: 
Source Field: 
Source Table: 

Comment Memo 

AllowZeroLength: 

Attributes: 

Collating Order: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

Description: 

Ordinal Position: 
Required: 
Source Field: 
Source Table: 

Explanation Memo 

AllowZeroLength: 

Attributes: 

Collating Order: 

ColumnHidden: 

ColumnOrder: 

ColumnWidth: 

Description: 

Ordinal Position: 
Required: 
Source Field: Explanation 
Source Table: 

Relationships 

Referencel 



50 

False 

Variable Length 

General 

False 

Default 

1890 

Polaris template type to use with this element 

Text Box 

4 

False 

TemplateType 
ControlAssemblyCatalog 



True 

Variable Length 

General 

False 

Default 

6012 

a brief comment on the use of the control 
assembly - should fit into 2 or 3 lines 
5 

False 
Comment 

ControlAssemblyCatalog 



False 

Variable Length 

General 

False 

Default 

Default 

a longer comment about properties of the 

assembly 

6 

False 



ControlAssemblyCatalog 



ControlAssemblyCatalog DCCEIements 

ControlAssemblyCataloglDControlAssemblyCatalogID 
Attributes: Not Enforced 

Attributes: One-To-Many 

Referencel 1 
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ControlAssemblyCatalog DCCActions 



ControlAssemblyCataloglDControlAssemblyCatalogID 
Attributes: Not Enforced 

Attributes: One-To-Many 

Reference2 

ControlAssemblyCatalog DCCEIements 

ControlAssemblyCataloglDControlAssemblyCatalogID 
Attributes: Not Enforced 

Attributes: One-To-Many 

Reference6 

ControlAssemblyCatalogControlAssemblylnstances 

ControlAssemblyCataloglDControlAssemblyCatalogID 



Not Enforced 
One-To-Many 



Number of Fields 
1 

False 
19 

False 
False 

PrimaryKey 
True 
True 
True 

ControlAssemblyCatalogID, Ascending 



Attributes: 
Attributes: 

Table Indexes 

Name 
PrimaryKey 

Clustered: 
Distinct Count: 

Foreign: 

Ignore Nulls: 

Name: 

Primary: 

Required: 

Unique: 

Fields: 

User Permissions 

ACR 

admin 

ALA 

ALA2 

BJB 

CPI 

Group Permissions 

Admins 

Guests 

LETTERS 

MODIFY 

READ ONLY 

REPAIR 

Users 

[00655] Code Generation 240 is performed by a system which builds a SmallTalk tree 

that is organized via a template file. The organization and logic associated with this 
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processing is presented in detail below in a section entitled Template Language. A template 
architecture facilitates descriptions of discrete part manufacture. Transfer Machine templates 
are types that are encapsulated with data and logic associated with the templates. Template is 
not an object but a specification for transfer machine. Information organized in a tree 
structure. 

[00656] TM1- All transfer machines will have some level of indexes. Modular list of 

type indexers - conveyers, transfers, shuttles, ... 

TM2 - Master control panel B push buttons etc. 

TM2 - Transfer Machine Tree for generating according to rules For Machines, batch 
(cookie) 

[00657] Because of understanding of Discrete parts manufacture, a generic model 

results that allows the granularity and modularity to be architected and organized in a 
structure that works well for diagnostics. The architecture lends itself to adding diagnostics 
in a modular. Key to the diagnostics is the system provides a structured environment that 
lends itself to modular diagnostics which are tied to the individual components in a logical 
manner. This allows a designer to have diagnostics architected into the actual components. 
[00658] Business Model utilizes a simulation to represent real world activities in a 

componentized fashion. Utilize a well defined interface (API) to obtain information &/or 
modify the real world. Export the interface as an OLE interface. They are defining the 
interface now. However, to utilize it today, they use Smalltalk and send strings in the OLE 
interface representative of Smalltalk commands. 

[00659] Instead of commands to the existing system via scripts, there will be an 

architected API to the business model. Create an object of discrete axis made up of XYZ 
component. Builds a tree, builds an access model and sends commands to build the code. 
Sending commands instead of a text string that is interpreted. With the template library, a 
user can add components. Sometimes the new component will need some definition to be 
added on the fly. 

[00660] The Causal Model Structure 250 is an expert system that relates generally to 

discrete event control systems that control the operation of an automated machine, and more 
particularly to a system and method for developing diagnostic rules by observing the 
behavior of the machine and for using the diagnostic rules to detect malfunctions in the 
behavior of the machine. 

[00661] Discrete event control systems, such as an automated industrial control 

system, generally control a machine having a large number of components (e.g., sensors and 
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actuators), which may malfunction due to transient errors and other hard or soft failures. 
Because of the immense number of possible failure points in the machine, attempts have been 
made to provide control systems that automatically diagnose the malfunction and pinpoint the 
failure point, thus reducing costly down-time of the industrial plant. 

[00662] Known systems have approached the diagnostic problem with varying success. 

For example, the diagnostic engines of prior art systems often are based on state-machine 
models that can detect only certain hard failures. Thus, transient errors and the erroneous 
occurrence of events are not diagnosed and predictions of malfunctions are not feasible. 
Further, such diagnostic engines often must be explicitly programmed. Or, if the engine is 
capable of autonomously learning the behavior of a machine, the learning session often is 
based on data gathered while the machine is operating in one machine state, in a fixed 
environmental condition, and at the beginning of the life of the machine. Accordingly, real- 
time changes in the behavior of the machine, that may be due to environmental conditions or 
the natural wear and aging process, are often erroneously diagnosed as malfunctions. To be 
able to take the various operating conditions into account, the diagnostic engine must either 
undergo a lengthy reprogramming process or be subjected to a new learning session. 
[00663] Prior art systems also generally are incapable of discerning the optimum state- 

machine model to use for developing the rules to diagnose the behavior of the machine. For 
example, the state-machine model will include a number of known sequential and temporal 
patterns that indicate the proper occurrences of the various discrete events associated with the 
manufacturing process. The diagnostic engine, however, may indiscriminately develop 
diagnostic rules based on these patterns. Thus, a particular rule may be based on a pattern 
corresponding to a known causal relationship between events, a pattern including a sequence 
of a large number of discrete events, or a pattern including a long time interval between 
discrete events. Each of these scenarios presents disadvantages and inefficiencies. In 
particular, restraining diagnostic rules to known causal relationships prevents the engine from 
selecting non-intuitive timing patterns that may produce simpler, more efficient rules. 
Moreover, a long sequential pattern necessitates the use of a larger amount of memory to 
store the occurrences of the multiple discrete events in the pattern and consumes more 
computing power, while a rule based on a long temporal pattern may result in a tardy 
diagnosis of a machine malfunction. Further, known diagnostic engines typically are not 
capable of determining the minimum number of patterns necessary to adequately diagnose 
the machine's behavior and predict malfunctions or of judging which patterns provide the 
most reliable indicators of the machine's health. 
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[00664] Accordingly, it would be desirable to develop a versatile diagnostic engine for 

discrete event control systems capable of discriminately developing diagnostic rules for 
diagnosing the behavior of an automated machine. The diagnostic engine would not be 
restricted by known causal relationships and, thus, could autonomously select and learn the 
optimum discrete event patterns for reliably diagnosing and predicting the behavior of the 
machine. Moreover, the diagnostic engine would be capable of automatically adapting to 
changed operating conditions of the machine, such as environmental variations, modifications 
to the machine, wear and aging of the machine, and different machine states. 
[00665] The present invention comprises a system and method for developing 

diagnostic rules that are based on discrete event timing patterns that occur during operation of 
the machine. The system and method further evaluate the occurrences of the discrete events 
relative to the diagnostic rules to identify malfunctions in the behavior of the machine. 
[00666] According to a first embodiment of the invention, a system and method for 

developing diagnostic rules for diagnosing the behavior of a machine is provided. The 
system and method include a plurality of control elements which cooperate to perform at least 
one discrete event process and which are configured to transition between at least two 
different states. Each state transition represents a discrete event in the process, and the 
occurrence of each discrete event is communicated to a main controller. The main controller 
is configured to detect a timing pattern in the occurrence of the discrete events, which 
includes a trigger event, a result event, and a time interval between the trigger and result 
events. A diagnostic rule is then defined based on a statistical analysis of repetitions of the 
timing pattern. The diagnostic rule is then updated in real time based on a detected change in 
the timing pattern. 

[00667] According to one aspect of the invention, the statistical analysis includes 

calculating a mean time interval between the trigger and result events and a standard 
deviation from the mean time interval. A diagnostic rule is defined based on the statistical 
analysis if the timing statistics satisfy certain defined criteria. For example, a rule may be 
defined if the magnitude of the ratio of the standard deviation to the mean time interval is less 
than a predetermined maximum magnitude. Alternatively, the diagnostic rule may be defined 
if the duration of the mean time interval is less than a predetermined maximum duration. 
[00668] In another aspect of the invention, a diagnostic rule may be replaced due to a 

detected change in the timing pattern. For example, the main processor may detect a change 
in which the result event follows a different trigger event. This change in effect creates a new 
timing pattern. If the standard deviation associated with the new timing pattern is smaller 
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than the standard deviation associated with the original timing pattern, the main processor 
will replace the original diagnostic rule with the new rule. 

[00669] Alternatively, a machine has a first machine state for performing a first 

discrete event process and a second machine state for performing a second discrete event 
process. The main processor looks for a timing pattern common to at least both machine 
states and then defines a diagnostic rule based on the common timing pattern. 
[00670] In another embodiment, a plurality of control modules are coupled to a 

communication link to communicate the occurrences of the discrete events to a main 
processor. Each of the control modules is configured to detect state transitions of at least one 
of the control elements. In anther aspect, a method for diagnosing the behavior of a machine 
configured to perform a discrete event process is disclosed. A plurality of control elements 
are configured to transition between at least two states. The occurrence of each state 
transition, which represents a discrete event in the process, is communicated to a main 
processor via a communications link. The main processor is configured to detect in real time 
a timing pattern in the occurrences of the discrete events, including a trigger event, a result 
event, and a time interval between the trigger and result events. A diagnostic rule is then 
defined based on a real-time statistical analysis of repetitions of the timing patterns. 
Occurrences of the discrete events are evaluated in real time relative to the diagnostic rule to 
identify whether a malfunction in the machine's behavior is present. 
[00671] Automated control systems, such as are used in manufacturing plants, are 

often used to control an industrial machine comprising a large number of sensors and 
actuators which cooperate to perform a dynamic process, such as a manufacturing or 
assembly process. As the automated system runs, the sensors and actuators (i.e., "control 
elements") transition between states in repetitive sequential, and oftentimes temporal, 
patterns. For example, in an automated system which controls a machine, such as an 
automated assembly line, a proximity sensor will transition between states, indicating the 
presence of an object (e.g., an empty bottle). Some time interval after this event, an actuator 
will transition between states, indicating, for instance, the initiation of an operation on the 
object (e.g., filling the bottle with a liquid). Next, a photodetector sensor will transition 
between states, indicating that the bottle is full. If the assembly line is functioning properly, 
the timing relationships between these discrete events will be quite regular. If, however, any 
component of the system malfunctions, the regular timing patterns will be disrupted. 
Accordingly, these regular timing patterns can provide reliable behavioral indicators useful 
for diagnosing the machine's health. 
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[00672] However, these timing patterns may vary over the life of the machine because 

of environmental factors, modifications of the machine, normal wear on the components, and 
other variables. Moreover, the timing patterns may vary depending on the state of the 
machine. For example, in the above-described scenario, the same assembly line may be used 
to fill both large bottles and small bottles. As another example, the conveyor speed may 
change from one state to the next. Accordingly, a variation in the duration of the time 
interval between initiating and completing the injection of the bottle with fluid will 
necessarily exist but will not be indicative of a malfunction. The present invention provides a 
system and method for diagnosing the machine's behavior which are capable of adapting to 
such operational changes. In accordance with this system and method, diagnostic rules are 
discriminately defined, selected, and updated based on the observation of the machine's 
discrete event timing patterns. 

[00673] Referring now to Figure 5a, a block diagram representation of a system 510 

according to a preferred embodiment of the invention is illustrated. System 510 includes a 
main processor 512, a communication link 514, a controller 516, and a machine 517 which 
comprises a plurality of control elements 518. Control elements 18 include a plurality of 
sensors and actuators which cooperate to perform a dynamic, discrete event manufacturing 
process. A control program, which is stored in a memory 520 of controller 516 and executed 
by the controller's processor (not shown), governs the manufacturing process during which 
control elements 518 transition between states in a deterministic sequence as a result of the 
flow of materials or parts. 

[00674] Each state change of a control element 518 is a discrete event that is detected 

by controller 516 and stored as data in its memory 520. For example, in the preferred 
embodiment, controller 516 is a programmable logic controller, such as a PLC-5 available 
from Allen-Bradley Company of Milwaukee, Wisconsin, which is programmed to 
periodically scan the control elements 518 to determine their respective states. Controller 
516 then compares the state of each element to the value of its state on the previous scan. A 
state change represents the occurrence of a discrete event, and a list of discrete events is 
accumulated in memory 520. Controller 516 reports the discrete events to main processor 
512 via communication link 514, which comprises, for example, copper conductors, an RF 
link or other types of links suitable for conveying digital data. 

[00675] In the preferred embodiment, main processor 512 is embodied in a general 

purpose personal computer and includes, for example, a microprocessor and a memory for 
storing a diagnostic engine 522 and a data file 524. Alternatively, main processor 512 may 
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be incorporated within controller 516. System 510 further includes a user interface 526 
which may include a display (e.g., the personal computers CRT or LCD display, or a 
peripheral display device) and a separate display memory for providing for the output of text 
and graphics from main processor 512, a keyboard allowing for the entry of alphanumeric 
characters to processor 512, and a mouse that facilitates the manipulation of graphical icons 
which appear on the display. 

[00676] The user interface 526 preferably resides on a software enabled display 

including a variety of control windows, data display windows, and dialogue boxes. For 
example, the control windows and dialogue boxes may include icons and text which aid in 
configuring system 510. The data display windows may be used to display the occurrences 
of discrete events in a graphical format. Further, existing and active rules may be displayed 
in either in a graphical or tabular format. Malfunctions may also be displayed graphically or, 
alternatively, symbolically or as a text message in a dialogue box. 

[00677] Referring still to Figure 5a and as is well known in the art, processor 512 may 

further include various driver and interface circuitry (not shown) to manage the flow of data 
on communication link 514. For example, the discrete event data reported from controller 
516 is conveyed to data file 524 through the driver and interface circuitry. The discrete event 
data in file 524 may then be passed to diagnostic engine 522. The cognitive engine 522 
preferably is a software program which can operate in either a learning mode or a diagnosing 
mode. During learning, engine 522 is configured to analyze the discrete event data in order 
to define diagnostic rules, and, during diagnosing, engine 522 evaluates the behavior of 
machine 517 relative to the diagnostic rules. The cognitive engine 522 may define rules and 
evaluate behavior in real-time or, alternatively, the discrete event data may be stored in the 
memory of processor 512, or written to a data storage disk (not shown), for off-line learning 
of diagnostic rules or evaluation of the machined behavior by diagnostic engine 522. 
[00678] Learning Diagnostic Rules 

During a learning mode, diagnostic engine 522 observes the occurrences of the 
discrete events to find repetitive sequences of events which occur in a consistent timing 
pattern. Each timing pattern preferably consists of two discrete events (i.e., a trigger event 
and a result event) and a time interval between the two events, although diagnostic engine 
522 is not prohibited from selecting timing patterns which include more than two discrete 
events. The diagnostic engine 522 then defines diagnostic rules based on a statistical analysis 
of the repetitive timing patterns, compares existing rules to newly defined rules to determine 
the optimum rules for evaluating the machine's behavior, and updates the existing rules by 
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either updating the statistical analysis based on further repetitions of the timing pattern or 
replacing the existing rules with better diagnostic rules. 

[00679] The various steps involved in obtaining and analyzing the discrete event data 

for rule learning are illustrated in the flow chart of Figure 5b. In the preferred embodiment, 
as discussed above, the scan is performed by controller 516 (block 528). However, in 
alternative embodiments the scan may be performed by other elements of system 510, such as 
main processor 512. In any event, and regardless of whether reported in real-time or read 
from memory or disk during an off-line analysis, the occurrences of discrete events are 
communicated to diagnostic engine 522, which then determines whether the discrete event 
has been previously detected (block 530) and whether the discrete event is a trigger event for 
any existing rules (block 544), is a potential or established result event for any rules (block 
550), or is an event which has been eliminated as a candidate for a potential rule (block 552). 
The first time a discrete event is detected, it is recorded as an expected event in a file stored 
in memory of main processor 512. The state of control elements which never experience a 
discrete event (i.e., do not transition between states) are also stored in this file. During 
diagnosis, engine 522 may reference this file to identify malfunctions if the occurrence, of a 
discrete event or a state of a control element has been detected that was not previously logged 
as an expected event. 

[00680] Returning to Figure 5b, if the detected discrete event is a trigger event of any 

existing rules, then the event's time of occurrence is recorded (block 546). Otherwise, if the 
discrete event can be a result event for any rules (block 550), then diagnostic engine 522 
determines the timing interval between the discrete event and all possible trigger events 
(block 534). A statistical analysis is then performed (block 536) which involves 
incrementally calculating a mean time interval between trigger and result events and a 
standard deviation about the mean time interval as further repetitions of trigger/result timing 
patterns are detected. 

[00681] Next, if a particular trigger/result timing pattern does not correspond to an 

existing rule (block 537), then the timing statistics of the pattern are evaluated to determine 
whether the timing pattern is adequate to define a new diagnostic rule (block 38). In the 
preferred embodiment, a minimum of three repetitions of the timing pattern must be observed 
before the timing statistics can be evaluated to provide the basis for a diagnostic rule, 
although clearly a greater number of repetitions would be desirable. Further, if a machine is 
capable of operating somewhat differently at some times than others (e.g., a conveyor system 
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in which palates are randomly merged from two conveyor lines), the timing statistics will not 
be sufficient until diagnostic engine 522 has experienced the different operational situations. 
[00682] Various criteria, or combinations of the criteria, may be used to evaluate the 

timing statistics. For example, a timing pattern having a mean time interval or a standard 
deviation that is longer than the cycle time of the manufacturing process will not provide the 
basis for a useful diagnostic tool. Further, examining the magnitude of the standard deviation 
and/or the ratio of the standard deviation to the mean time interval may reveal that a resulting 
diagnostic rule will not be sufficiently precise. If the evaluation criteria are not met (e.g., the 
mean time interval, the standard deviation, and/or their ratio are too large), then the timing 
pattern will be discarded as a candidate for a diagnostic rule (block 540), and the timing 
pattern's discrete events may even be tagged such that they are eliminated as potential 
candidates for any rules. If, however, the criteria are met and the pattern's result event is not 
already a result event in an existing rule (block 562), then a diagnostic rule will be defined 
using the timing statistics of that timing pattern (block 542), thus dictating the timing 
relationship between the trigger and result events. 

[00683] As will be explained in more detail below, the diagnostic rules preferably are 

symmetric rules. That is, the trigger and result events each must occur within an error band 
about the mean time interval of the other. The error band, which may either be fixed or 
selectable by a user, is a multiple of the standard deviation and, preferably, is five times the 
standard deviation. 

[00684] Once the diagnostic rules are defined, they are either retained or enter a rule 

competition, as will be explained in detail below. If the rules are retained, they may be 
updated continuously, including replacement, during the learning process based on the 
incremental accumulation of timing statistics from further repetitions of the timing patterns. 
As illustrated in Figure 5b, if a timing pattern occurs that corresponds to an existing 
diagnostic rule (block 537), the accumulated timing statistics for the pattern are evaluated 
using the criteria discussed above (block 539). If the accumulated statistics for the rule no 
longer meet the evaluation criteria, then the rule may be discarded (block 541). If, however, 
the accumulated statistics are good, then the statistics of the rule are updated to reflect the 
further repetitions of the associated timing pattern (block 543). 

[00685] The evaluation criteria applied in blocks 538 and 539 may also provide a basis 

for rating the merit of timing patterns and existing diagnostic rules. For example, rather than 
discarding an existing rule if the timing statistics do not meet the criteria, the rule may merely 
be deactivated. In such a case, the rule remains in existence and is a candidate for activation 
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if its future accumulated timing statistics meet the evaluation criteria. Alternatively, if an 
existing rule's timing statistics fail to satisfy the evaluation criteria by a wide margin, then the 
rule may not only be discarded, but also tagged as a rule that should never be considered 
again. Likewise, if a timing pattern's statistics fail to satisfy the criteria by a wide margin, 
then future occurrences of the pattern, or even one or all of the discrete events associated with 
the pattern, may be ignored. 

[00686] A detected break or inconsistency in a timing pattern also warrants removal of 

the timing pattern or the corresponding rule from further consideration. For example, a 
timing pattern or rule may be discarded either if its result event occurs without the prior 
occurrence of its corresponding trigger event (not shown); or if the rule's trigger event occurs 
a second time without the intervening occurrence of its corresponding result event (not 
shown); or if a machine state ends after a trigger event has occurred but before its 
corresponding result event occurs (not shown). Any of these exemplary breaks in a timing 
pattern indicates that a rule based on that timing pattern will not provide a consistently 
reliable indicator of the machine's behavior. 
[00687] Rule Competition 

To minimize memory requirements and optimize the computing efficiency of main 
processor 512, it is preferable to select only a minimum number of timing patterns. The 
selected timing patterns should also provide the most precise indicators of the machine's 
behavior. To achieve these goals, a rule competition procedure may be initiated in which an 
existing rule can be updated by replacing it with a better rule. The rule competition further 
allows diagnostic engine 522 to select diagnostic rules that may not necessarily have been 
intuitive from a knowledge of the machine's architecture. 

[00688] Figure 5b is a flowchart setting forth the detailed logic of cognitive analysis in 

accordance with a preferred embodiment. A timing pattern enters into competition with an 
existing rule if they both include the same result event (block 562). The statistics of the 
timing pattern are compared to the statistics of the existing rule to determine whether the 
existing rule indeed provides the most accurate and efficient diagnosis of the behavior of 
machine 517 (block 566). If the statistics of the timing pattern are better than the statistics of 
the existing rule, then the existing rule is updated, in effect, by discarding the existing rule 
(block 568) and creating a new rule based on the better timing pattern (block 542). In the 
preferred embodiment, the statistics which include the smallest standard deviation are 
deemed to provide the basis for the better rule. If, however, the magnitudes of the two 
standard deviations are close in value, then the mean time intervals are also compared. 
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Although the above-described rule competition is presently preferred, diagnostic engine 522 
may also be set to retain more than one rule for a given result event and may specify other 
criteria, or combination of criteria, for the competition. 
[00689] State-Dependent Learning 

The selection of the best diagnostic rules may also be affected by whether machine 
517 is capable of running in more than one machine state. For example, machine 517 may be 
used to manufacture several different types of parts (e.g., a standard truck cab and an 
extended truck cab), and, thus, the details of the machine's operation will be somewhat 
different in each state. For instance, some control elements 518 may not be activated in one 
of the states, or, if active, the timing patterns may be different. Maintaining separate rule 
bases for each different state would be prohibitive in terms of the computational and memory 
requirements for main processor 512. On the other hand, defining a single set of rules that 
will apply to all machine states will be difficult in most situations. Therefore, it is preferable 
that the diagnostic engine 522 observe the operation of machine 517 in all states, and then 
define a maximum number of diagnostic rules based on timing patterns that are common to 
all states and a minimum number of rules based on timing patterns peculiar to a particular 
state. Further, each resulting rule is preferably tagged with code that indicates the state or 
states to which the rule applies. 

[00690] Before defining a common diagnostic rule, the timing statistics of the common 

timing pattern are subjected to the same evaluation process as described above. If the 
statistics of the common timing pattern do not satisfy the evaluation criteria (e.g., the mean 
time interval, the standard deviation or their ratio are too large), however, then diagnostic 
engine 522 will attempt to discover a version of the common timing pattern that will produce 
an acceptable diagnostic rule. For example, if the time interval between the trigger and result 
events varies between states as a result of a change in conveyor speed and a measurement of 
conveyor speed is available, then a diagnostic rule can be defined having a mean time interval 
that is a function of the measured speed. As another example, if the manufacturing process 
can diverge into one of multiple courses of action and then resume a single course, forward or 
backward-looking diagnostic rules can be defined that diagnose the final and initial events of 
the individual courses of actions respectively, as will be explained below. 
[00691] Symmetric and Forward and Backward-Looking Rules 

In general, the diagnostic rules can be either symmetric rules, forward-looking rules, 
or backward-looking rules. In a symmetric rule, an event B always follows an event A and 
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vice versa. The following timing pattern satisfies the requirements of a symmetric rule: 
B A- — B 

[00692] In a forward-looking rule, event A is always followed by event B, but not vice 

versa. Both of the following examples of timing patterns satisfy the test for a forward- 
looking rule: 

B- — A- — B 
B B 

[00693] In a backward-looking rule, event B is always preceded by event A, but not 

vice versa. Thus: 

B- — A- — B 
B~A— A — B 

[00694] Preferably, the diagnostic rules are symmetric rules, and thus also satisfy the 

tests for forward and backward-looking rules. However, if a symmetric rule does not satisfy 
the evaluation criteria, a forward or backward-looking rule may be defined instead, and, in 
the preferred embodiment, the rule includes a code indicating whether the rule is a 
symmetric, forward-looking, or backward-looking rule. Backward and forward-looking rules 
have uses other than that discussed above. For example, if a control element experiences 
bounce, the element's change of state can still be the trigger event of a backward-looking rule. 
[00695] Groupin2 of Control Elements 

For machines having an extremely large number of control elements 518, the 
definition of diagnostic rules could involve extensive computation and large amounts of 
memory. Thus, in the preferred embodiment of the invention, diagnostic engine 522 can 
employ alternative strategies that prevent the amount of computation time and the amount of 
memory from becoming excessive. For example, control elements 518 may be divided into 
independent groups which have little or no interaction with other groups. Rules are then 
defined on a group basis, and the rules for each group include only those discrete events 
which correspond to elements 518 within that group. 

[00696] In practice, however, groups of elements 518 usually do interact with one 

another, but only on a limited basis. Accordingly, some of the elements of one group can be 
selected to be visible to another group and are thus included in the rules for the latter group. 
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Selecting the visible elements may be easily accomplished based on a knowledge of the 
architecture of the control system. Further, grouping of control elements 518 for diagnostic 
purposes is particularly suited for a control system which includes multiple distributed 
controllers 516. In such a distributed control system, each controller 516 is associated with a 
group of control elements 518, and, thus, the system architecture is easily discernible. In 
alternative embodiments, other strategies may be employed, such as performing the rule 
definition process in stages in which only certain groups of control elements 18 participate at 
a given time. 
[00697] Diagnosis 

Once diagnostic rules are learned, diagnostic engine 522 may be set to the diagnostic 
mode in which incoming discrete events are evaluated relative to the diagnostic rules to 
identify existing or potential malfunctions in the behavior of machine 517. The evaluation of 
the discrete events may be performed in several alternative manners. For example, referring 
to Figure 5c, the timing relationship between the trigger and result events may be evaluated 
relative to the timing statistics learned during the learning process (blocks 585, 582, 588, and 
590). Accordingly, if, for instance, the result event does not occur within five learned 
standard deviations of the learned mean time interval and the corresponding rule is either a 
symmetric or forward-looking rule, then system 510 will identify that a malfunction in 
machine 517 has occurred (block 586). 

[00698] Alternatively, and preferably, the timing statistics are incrementally updated in 

real time based on observing further repetitions of the timing patterns associated with the 
diagnostic rule. For example, in the preferred embodiment illustrated in Figure 5c, if a 
scanned discrete event (block 572) is the trigger event for an active rule (block 574), a rule 
timer is started (block 576). If the result event for the triggered rule occurs (block 578) 
within five standard deviations of the mean time interval (block 580), then the timer is 
stopped (block 582) and the timing statistics are updated (blocks 588 and 584). If, however, 
a result event occurs and its corresponding rule has not been triggered (block 578), or if the 
result event does not occur within the allotted time interval (block 580), the system 510 
identifies that a malfunction in machine 517 has occurred (block 586). 
[00699] In a preferred embodiment, both the learned timing statistics and the updated 

timing statistics are retained as separate files in the memory of main processor 512. The 
learned timing statistics thus provide a baseline reference for evaluating the performance of 
machine 517, while the updated timing statistics, which may be regularly replaced (e.g., on a 
daily, weekly or monthly basis), provide a mechanism by which the diagnostic rules can 
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autonomously adapt in real time to changed operating conditions. For example, in the 
preferred embodiment, occurrences of discrete events may be evaluated by determining 
whether a result event occurs after its trigger event within a multiple of the learned standard 
deviation of the updated mean time interval. Using the updated mean time interval in 
conjunction with the learned standard deviation ensures that system 510 does not interpret 
changes in the timing pattern caused by manufacturing variations, such as normal machine 
wear and aging, temperature or other environmental conditions, as machine malfunctions. In 
alternative applications, however, both the updated mean time interval and the updated 
standard deviation may be used or only the updated standard deviation may be used. As yet 
another alternative, the diagnostic rules may be updated by replacing the learned timing 
statistics with the updated timing statistics. 

[00700] The diagnostic engine 522 preferably also tracks (block 588) the updated 

timing statistics against the learned timing statistics, although the tracking feature is optional 
(block 590). Accordingly, engine 522 can diagnose a large change or drift in the updated 
timing statistics relative to the learned statistics (block 592) as indicative of an existing or 
potential malfunction in the behavior of machine 517 (blocks 586, 596). 
[00701] The criteria that engine 522 employs to identify malfunctions may vary 

depending on the type of diagnostic rule used. For example, symmetric and forward-looking 
rules can be used to identify a malfunction (a) when a result event occurs either too soon or 
too late after its trigger event, (b) when a trigger event reoccurs before its corresponding 
result event has ever occurred, or (c) when a machine state ends before a result event occurs 
for a rule that has been triggered. Symmetric and backward-looking rules can be used to 
identify a malfunction, for example, (a) when a trigger event occurs either too early or too 
late relative to its corresponding result event, (b) when a result event reoccurs without a 
corresponding reoccurrence of its trigger event, or (c) when a result event occurs during a 
particular machine state and its trigger event did not precede it while in that machine state. It 
should be understood that these types of malfunctions are offered by way of example only, 
and that one skilled in the art would recognize that other types of malfunctions may be 
readily diagnosed. 

[00702] Upon detection of a malfunction, main processor 512 generates an error signal 

indicative of the malfunction and communicates it to user interface 526. User interface 526 
preferably includes a display driver (not shown) which, in response to the error signal, 
communicates a display signal to the display screen which then provides visible indicia 
indicating that a malfunction has occurred. For example, alphanumeric characters may 
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Find all top level Activities 

SELECT * FROM Activities WHERE ParentActivitylD = '0' 

Creat a Timing Diagram 
INSERT INTO BarCharts 

(BarChartID, BarChartStrng, BarChartDescr, Model D) 
VALUES ($BarChartlD, 'SbarChartStrng', 'From CATIA', 1) 
Create an Edge 
INSERT INTO Edges (EdgelD, EdgeNum, BarChartID) 
VALUES ($EdgelD, $edgeCount, $BarChartlD) 
Find all Requests on this Timing Diagram 
SELECT * FROM Activities WHERE ParentActivitylD = '$ParentActivitylD' 

Activities give rise to both BarCharts and CNextRequests, depending on their 
position in the hierarchy. A top level (parentless) Activity is always a BarChart, and a 
lower level Activity is always a Request, but if the lower level Activity has children, it 
will give rise to a subsidiary BarChart as well as a Request. 

Create a CNextRequest 
INSERT INTO CNextRequests 

(RequestID, LeftEdge, BarChartID, RequestOrder, Activity, Resources, 
SubBarChartID) 

VALUES ($RequestlD, 0, $BarChartlD, 0, '$activitylD\ NULL, 0) 
Count subsidiary Activities 

SELECT COUNTf) AS ChildCount FROM Activities 

WHERE ParentActivitylD = '$activitylD' 
Update SubBarChartID in CNextRequest 

UPDATE CnextRequests 

SET SubBarChartID = SnewBarChartID 
WHERE RequestID = $RequestlD 

Find all Requests on left Edge of Timing Diagram 

SELECT * FROM Activities 

WHERE Activities. ParentActivitylD = ^ParentActivitylD' 
AND NOT EXISTS (SELECT * FROM ActivityPredecessors 
WHERE Activities. Activity ID = ActivityPredecessors.ActivitylD) 
This query may be paraphrased as "select those Activities belonging to this 
BarChart and lacking a predecessor Activity". 

Update LeftEdge of Requests with no Predecessors 
UPDATE CnextRequests 
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SET LeftEdge = $edgelD 
WHERE CNextRequests. Activity = '$ActivitylD' 
Find all Requests for next Edge 
SELECT R2.RequestlD 

FROM CNextRequests AS R1, CNextRequests AS R2, ActivityPredecessors 
AS AP1 

WHERE R1. LeftEdge = $oldEdge 

AND APLPredecessorActivitylD = R1 .Activity 
AND R2.Activity = AP1 .ActivitylD 
This query may be paraphrased as "select those Requests whose predecessor 
Activity mapped to a Request linked to the preceding Edge". 
Update LeftEdge of other Requests 
UPDATE CnextRequests 
SET LeftEdge = $edgelD 

WHERE CNextRequests. RequestID = $RequestlD j 
Select BarChart for export 

SELECT * FROM [BarCharts] WHERE BarChartID = $BarChartlD 
Create Ordered Edge List 
SELECT * FROM Edges 
WHERE BarChartID = $BarChartlD 
ORDER BY Edges.EdgeNum 
Select Requests for export 
SELECT * FROM Requests 
WHERE Requests.LeftEdge = $EdgelD 
ORDER BY Requests.RequestOrder 
Lookup Request Attributes 
SELECT ControlAssemblylnstances. Label AS InstanceLabel, 
DCCActions. Label AS ActionLabel, 
DCCEIementsTimes.Time 
FROM Requests, 

ControlAssemblylnstances AS Cai, 
DCCActions, 
DCCEIementsTimes 
WHERE Requests.RequestID = $RequestlD 
AND Requests. ControlAssemblylnstancelD = Cai.ControlAssemblylnstancelD 
AND DCCActions. DCCActionsID = Requests.DCCActionsID 
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appear on the display screen stating that a particular discrete event has occurred at an 
improper time. Or, a user may provide a custom message to be displayed for a fault of a 
particular rule or rules. Alternatively, the display may provide a graphical representation of 
the faulted rule or rules which highlights the problem area, such as with a flashing or colored 
marker. In other embodiments, other types of displays or audio components for effectively 
communicating the occurrence of the malfunction, either alone or in combination, may be 
readily envisioned by those skilled in the art. 

[00703] In addition to identifying timing errors, the present invention can identify 

malfunctions that are characterized by the occurrence of an unexpected event. For example, 
after having observed machine 517 in all operating states and conditions, diagnostic engine 
522 may detect the occurrence of a discrete event that it has never seen before or that had 
never occurred while the machine was operating in the present machine state (i.e., the 
discrete event has not been recorded in the expected events file stored in memory of main 
processor 512) (block 598). This unexpected event may be indicative of a malfunction or of 
an unusual condition, such as the opening of a safety gate. In any event, diagnostic engine 
522 will generate an error signal (block 86) that is translated into an error message that is 
displayed on the display screen of user interface 526. 

[00704] Unexpected events also include detection of a control element which is in the 

wrong state. For example, in some machine states, a control element may never experience a 
discrete event and, thus, is always in one particular state. Accordingly, if engine 522 detects 
that the control element is in or has transitioned to the other state (block 598), the unexpected 
event will be diagnosed as a malfunction (block 586). 

[00705] It should also be understood that some discrete events may not be either a 

trigger or a result event for any diagnostic rule (blocks 574 and 578). In such a case, and 
provided the discrete event is not an unexpected event (block 598), diagnostic engine 522 
will simply ignore its occurrence (block 99). 

Although the foregoing description has been provided for the presently 
preferred embodiment of the invention, the invention is not intended to be limited to 
any particular arrangement, but is defined by the appended claims. For example, 
either the rule definition process or the diagnostic process, or both, may be 
performed off-line using discrete event data that has been stored in memory. Or, 
the diagnostic rules initially may be defined by a user and then may be updated or 
replaced based on real-time observation of discrete events. Alternatively, a user 
may manually modify the diagnostic rules after the rules have been defined based on 



-147- 



real-time observation. Further, the diagnostic rules may be based on other 
variations or types of statistical analyses of the repetitions of the timing patterns. 
Designer Studio 

The Designer Studio is a software tool set for integrating control system 
design, simulation, implementation and maintenance; and integrating the control 
system design with external product, process and machine (data) models. A user 
commences operation by opening a new or existing project. Figure 6 illustrates the 
user display for opening a project in accordance with a preferred embodiment. All 
existing projects are listed in the window 610 for a user to select from. When the 
user selects a project 610 it opens a Designer Studio window. Figure 7 is a 
Designer Studio window in accordance with a preferred embodiment. The first panel 
that is created when a project is opened is the Resources panel 710. In this panel, a 
filtered hierarchical list of the project resources is presented for further control 
definition. The timing diagram panel 720 is presented for sequencing workcell 
operations. It also joins the resources necessary to perform the operations at the 
appropriate times. The control resources window 730 provides an predictive list of 
control assemblies for a user to select from based on the resources 710 and the 
activities 720. 

Figure 8 is a Designer Studio display with control assemblies completed in 
accordance with a preferred embodiment. A hierarchical list of the control assembly 
types 810, control assembly instances 820, and control assembly instance requests 
830. One of the options that a user can exercise in the Designer Studio is the add 
operation 840 which invoked the add control assembly logic of the add operation. 
This prompts the user with an add control assembly dialog box. From the dialog 
box, a user can select a control assembly type and select the new button to go to the 
control assembly wizard Figure 9. 

Figure 9 is a control assembly wizard in accordance with a preferred 
embodiment. The information in the display acclimates a user with the wizard 
experience. 

Figure 10 is a control assembly wizard name operation in accordance with a 
preferred embodiment. The user must specify a name 1000 indicative of the new 
control assembly instance that will be generated utilizing this wizard. The user also 
has the option of selecting various options to initiate other processes to create wiring 
diagrams, diagnostics and documentation for the named instance of the control 
assembly. 
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Figure 11 is a control assembly wizard to select control resources in 
accordance with a preferred embodiment. The available resources of the 
appropriate type are presented to the user in a window 1 100. A user selects 
resources that will be controlled by the named control assembly instance from 
window 1100 and presented back to a user in a window 1110. Selection logic is 
provided which is consistent with the activity timing diagram 720. When a particular 
resource is selected, all other resources that conflict with that selected resource are 
greyed out to prevent conflict selection. 

Figure 12 is a control assembly wizard to label components associated with 
the control assembly in accordance with a preferred embodiment. Label comments 
1200 are entered for each of the components at the user's discretion. 

Figure 13 is a control assembly wizard summary in accordance with a 
preferred embodiment. When a user selects 1300 the wizard completion processing 
occurs and the control assembly is created conforming to the user's selections. 

Figure 14 is a Designer Studio display of a new control assembly integration 
in accordance with a preferred embodiment. The new control assembly instance 
1400 is added into the Control Resources control assembly tree utilizing the selected 
type and the data model of that particular type combined with the user selected 
information from the wizard and that combined information is written into the ECDB. 
The selected resources that are under the control of the newly created control 
assembly named IstClamps 1400 are the resources 1410 as shown in the Control 
Request Chart 1420 and 1430. The prescribed order of the mechanical operations 
for the resources 1410 refers to the time window that particular resources are 
utilized. The order of events from the prescribed order must be maintained in the 
Control request chart as illustrated by the placement of the Control Assembly's 1420 
and 1430. Other intervening assemblies can occur, but the prescribed order is 
always maintained. 

A popup window that details each of the types and instances of assemblies 
appears at label 1450. A Control Assembly type comprises the following information. 
A control component which is an entity that either sends a control signal, receives a 
control signal, or both sends and receives control signals. Examples of control 
components include a solenoid valve (receives), proximity sensor (sends), Robot 
interface (both), PanelView interface (both), pushbutton (sends), indicator light 
(receives) or a motor controller. 

Logic refers to the control and fault states, the transitions between states that 
the control components can attain (i.e., the state space of the control assembly), the 
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controller outputs which produce the transitions, and inputs to the controller 
determine the current state. 

For example, an n-sensor 
PartPresent (input) has states such as Part Absent, 
Part Present, Part out of position, Transitions 
Part Absent transitioning to a Part Present state. 
Part Present transititioning to a Part out of position state. 
Part out of position transititioning to a Part Absent state. 
Part Absent transititioning to a Part Present state. 
Part Absent transitioning to a Part out of position state. 
Part out of position transititioning to a Part Present state. 

There are also logic for Input only types, such as: 
all n off (Part Absent); 
all n on (Part Present); 
k of n on (k<n, k>0) (Part out of position); 
[00706] There are also logic for output only types, such as: 

[00707] ClearToEnterLight (output) (e.g., single light also could be multiple lights); 

which also has various states such as LightOn; LightOff with Transitions, such as: LightOn 

transitioning to LightOff; and LightOff transitioning to LightOn. 

[00708] There are also status based and causal based Diagnostics. 

[00709] Status-based diagnostics - specifies the step(s) that the machine is currently 

waiting to occur (if a fault occurs it specifies the step(s) that were waiting to occur at the time 

of the fault, i.e., the symptoms). 

[00710] Causal model-based diagnostics - use a model of causal relationships to 

develop rules that relate machine status to root causes. 

[0071 1] For example, consider that a human mechanic has incorrectly moved the 

mount location of a part present proximity sensor so that it is out of alignment. Then the 
Status-based diagnostics would place the following message in an internal diagnostic table 
that could be displayed: "waiting for part present sensor #2" (no automatic inference 
possible). 

[00712] In another situation, a proximity sensor on a clamp cylinder could fail. Then, 

the status-based diagnostics would place the following information into an internal diagnostic 
table that could be displayed: determines that a machine is "waiting for clamp cylinder 
2504A." 
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[00713] In a causal model-based diagnostic system the logic infers that the extend 

proximity sensor on cylinder 2504A has failed, or that cylinder 2504A is stuck and informs 
an operator accordingly. The causal model utilizes a set of rules and a tree structure of 
information to determine the probable root causes based on factual scenarios. 
[00714] Schematic A schematic (i.e., "wiring diagram") is a representation of the 

logical and functional connections among a set of control and mechanical components. The 
connections include electrical, pneumatic, and hydraulic. The preferred embodiment presents 
a view of each of these connection types and the bill of materials that make up the control and 
mechanical components of the control assembly type or instance. 

[00715] Figure 15 is a schematic of a pneumatic system of a control environment in 

accordance with a preferred embodiment. RS Wire is the application created and 
manufactured by the assignee. RSWire 1510 utilizes a computer aided design engine for 
creating, displaying, manipulating and storing schematics of electrical and hydraulic systems. 
Various views are all enabled withing the enterprise system in accordance with a preferred 
embodiment. System wide information, including detailed electrical, pneumatic and 
hydraulic information, is all stored in the ECDB. 
[00716] Visualization 

A visualization comprises entities within the control assembly that are useful to 
portray textually or graphically. For example, 

[00717] Control Components can be displayed as text or a graphical representation of 

the control component could be utilized. 

[00718] Logic can be displayed as LL, function blocks or in axis-like diagrams. 

Diagnostics can be displayed as status messages, causal messages and as indicators on a 
graphic display. The information includes a three dimensional depiction of a work cell. 
[00719] One way to streamline any type of programming is to provide predefined 

language modules which can be used repetitively each time a specific function is required. 
Because of the similar types of tools and movements associated with different machine line 
stations, industrial control would appear to be an ideal industry for such language modules. 
For example, various stations in a single machine line could employ drilling tools having 
identical limiting motion and configuration parameters. 

[00720] In this case the idea would be to design a ladder logic language module for a 

drill once, place the drill language module into a control library and thereafter, each time drill 
logic is required, download the drill language module into a control program. Similarly, 
language modules for other types of tools could be designed once and then used repetitively 
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to reduce programming and debugging time. The module library could be expanded until 
virtually all tool movements are represented. Library components would be viewed as "black 
boxes" with predefined interfaces, in much the same way that integrated circuits are used in 
the electronics industry. 

[00721] In addition, to make it easier to program in LL, a comprehensive module 

library would also facilitate automated LL programming using a programming editor. For 
example, an entire module library could be stored in the memory of an electronic editing 
apparatus. Using the apparatus, a user could designate all characteristics of a machine. 
Thereafter, using the designated characteristics, the apparatus could select language modules 
from the module library and assemble an LL program to control the machine. 
[00722] The module library approach would work quite well for certain applications 

like small parts material handling or simple machining. The reason for this is that the LL 
logic required for these applications tends be very small and highly reusable because the I/O 
count is minimal and interactions between modules are simplistic. 
[00723] Unfortunately, there are many areas of industrial control for which it is 

particularly difficult to provide reusable language modules due to relatively large and varying 
job specific I/O requirements and the complexity and variability of interaction between 
modules. 

[00724] One area of industrial control that defies the predefined language module 

approach is sequential control. Sequential control is the synchronization of individual tool 
movements and other subordinate processes to achieve a precisely defined sequence of 
machining operations. While it may be easy to enumerate all of the possible sequences 
involving just a few simple tool movements, the number of possibilities increases rapidly as 
the number and complexity of the tool movements increases, to the point where any attempt 
to enumerate them all is futile. 

[00725] For example, a typical machine station configuration may include five 

different tools, each of which performs six different movements for a total of thirty 
movements. In this case, each tool movement must be made dependent on the position of an 
associated tool. In many cases, movement of a tool must also be conditioned upon positions 
of all other tools at the station. In addition, tool movements at one station are often tied to 
tool movements at other stations or the completion of some portion of a cycle at some other 
station. Furthermore, tool movement may also be conditioned upon the states of manual 
controls. 
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[00726] Taking into account the large number of machine line tools, tool movements, 

manual control types, manual control configurations, and cross-station contingencies that are 
possible, the task of providing an all encompassing module library capable of synchronizing 
tool movements becomes impractical. Even if such a library could be fashioned, the task of 
choosing the correct module to synchronize station tools would probably be more difficult 
than programming required LL logic from scratch. 

[00727] For these reasons, although attempts have been made at providing 

comprehensive language module libraries, none of the libraries has proven successful at 
providing comprehensive logic to synchronize tool movements. In addition, none of the 
libraries has made automated LL programming a reality. Thus, typically synchronization 
programming in LL is still done from scratch. 

[00728] Therefore, in order to reduce programming time and associated costs, it would 

be advantageous to have a more flexible means of specifying control logic for controlling 
machine sequences. It would be advantageous if such a means enabled less skilled 
programmers to provide sequential control logic. Furthermore, it would be advantageous if 
reusable logic templates, comprising the basic components of a sequential control program, 
could be composed into a library of templates that would be employed to produce sequential 
control logic with consistent behavior and form. Moreover, it would be advantageous if such 
a library of templates could be accessed using a programming apparatus such as a personal 
computer, or the like, to further minimize programming time required to program machine 
sequential control in LL. 

[00729] In accordance with a preferred embodiment, a programming apparatus is 

disclosed to construct a bar chart image or graphical depiction on a computer screen which 
resembles a bar chart programming tool. A bar chart is a conventional controller 
programming tool that consists of a graphical cycle representation illustrating all related tool 
movements in a cycle. Control engineers regularly generate bar charts on paper to visualize 
sequences of motion. The apparatus gleans information from the bar chart image and, using a 
template based programming language, constructs a template based machine model. 
[00730] A template is a language module that includes some truly reusable machine 

logic and a section wherein other templates can be designated that are required to provide 
machine logic for job-specific control requirements. When compiled, the model provides 
complete LL logic for controlling sequenced tool movements. 

[0073 1] Thus, one object of the present invention is to provide an apparatus that can 

reduce the time and cost associated with programming sequences of tool movements in 
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cycles. Using the inventive apparatus, a user can quickly construct a bar chart image on a 
computer screen that contains all of the information necessary to sequence tool movements. 
The apparatus includes an editor that gleans all required information from the bar chart 
image, determines if additional templates are required to provide job specific logic and, 
where additional templates are required, creates required templates and populates existing 
templates with references to the new templates. Compilation is a simple process so that, after 
a bar chart image has been created, the apparatus itself can completely convert bar chart 
information into sequencing logic thus minimizing programming time and associated cost. 
[00732] Another object of the present invention is to minimize the amount of training 

required before a user is competent in programming sequencing logic. Control engineers are 
already familiar with the process of constructing and using bar charts as an aid for cycle 
visualization. Because the inventive apparatus interfaces with a user via a bar chart image, 
control engineers should be comfortable using the present apparatus. 

[00733] Yet another object is to provide a module library that includes logic that can 

be altered to accommodate job-specific requirements for sequencing cycle functions and 
making functions contingent upon various function conditions including function states in 
cycle, instantaneous states of other cycles, and instantaneous conditions of manual control 
devices. The present invention includes a "bucketing" means whereby certain conditions of 
related functions are placed in different groupings depending upon relationships between the 
functions and an associated function. Control logic including an output, is provided for each 
group indicating when all conditions in the group are true or when one or more are false. The 
outputs are mapped into the logic module associated with a function to provide synchronized 
automatic and manual function control that is conditioned as required, on the states of the 
related functions. In this way, function module logic is altered to accommodate job-specific 
requirements for a cycle. 
[00734] IV, Template Language 

In order to understand the template language concept, it is first necessary to 
understand that all machine attributes, including machine components, component physical 
and operational characteristics, and component movements, can generally be referred to as 
control-tasks and that there is a natural hierarchical relationship between various control- 
tasks. Any machine and associated industrial process can be subdivided into a network of 
separate, related control-tasks that form a hierarchy of control-tasks. For example, a single 
machine usually has specific control-tasks (i.e. indexers, stations, work-units, and movements 
. . .). While the machine includes several different physical tools or control-tasks, one of its 



-154- 



fundamental characteristics is that it includes a number of unique tools. There is a 
hierarchical relationship between the machine and its unique tools and every machine can be 
defined in part, by a list of its unique tools. 

[00735] Referring to Figure 16, a machine tree 1611 corresponds to machine 1610 is 
illustrated. In Figure 16, direct connection between two elements signifies a parent/child 
relationship between two elements where the higher control-task in the tree is the parent and 
the lower control-task is the child. Where a parent/child relationship exists, the child control- 
task represents one fundamental characteristic of the parent control-task. In Figure 16, the 
hierarchical relationship between the machine 1610 and the index er 1620 is illustrated at the 
top portion of the machine tree 1611. 

[00736] The most fundamental characteristic of index er 1620 is that it includes five 

stations 1630-1635 and therefore, stations 1630-1635 can be hierarchically related to the 
indexer as illustrated. Each work-unit is hierarchically related to its associated station and 
one or more axes are hierarchically related to each work-unit. 

[00737] In addition to the hierarchical relationship identified above, each machine tree 

1611 component can also have a direct relationship to an axis. For example, all of the 
indexer 1620, stations and work-units in machine 1610 may require a pneumatic air source 
for operation. Where a machine- wide air requirement exists, the machine 1610, as opposed 
to one of its child components, should control an air valve to provide air to all machine 
components. Thus, in addition to its list of indexers, other fundamental characteristics of a 
machine as a whole are axes that are directly connected to the machine 1610. In Figure 16, in 
addition to being directly connected to its indexer 1620, the machine 1610 is also connected 
to an air axis 1686 for opening an air valve. 

[00738] Similarly, the indexer 1620 is connected to a transfer axis 1688 for controlling 

the transfer bar for all stations 1630-1635. Moreover, each of the stations 1631-1634 that 
includes a clamp is connected to a different clamp axis for controlling an associated clamp. 
[00739] A third fundamental defining aspect of each tree component is whether or not 

the component requires a control panel. In the present example, the machine 1610 includes a 
main control panel 1658 for controlling the entire machine and therefore, a control panel 
1658 is shown on the machine tree 1611 directly connected to the machine 1610. In addition, 
the horizontal mill 1622 includes a local control panel 1657 for controlling only the mill 
1622. A control panel 1657 is shown directly attached to the horizontal mill in tree 1611. 
[00740] Therefore, the entire industrial process shown can be viewed as a machine tree 

1611 made up of the hierarchically-related components or control-tasks shown in Figure 16. 
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Each control-task can be entirely described by identifying its most fundamental 
characteristics, including control-tasks from the next hierarchical level, any directly- 
connected axis control-tasks and any directly-connected, control panel control-tasks. With 
this understanding of an industrial machine, template language can now be explained. 
[00741] The template language guides a user to assemble from a set of programming 

units called modules a complete and correct machine tree 1611. Individual modules are 
identified with templates, which include truly reusable control logic so that, when a template- 
based machine tree is compiled, a complete control program for an industrial process is 
produced. 

[00742] A template is a model program unit available for repeated use as a pattern for 

many modules based thereon. A template can be analogized to a data entry form wherein 
form identification can refer to either a blank instance of a master copy or a completed 
instance. In this description, the term "template" is used to mean the essence of a pattern as 
well as a completed instance of the pattern referred to also by the term "module". 
[00743] The template language includes two types of language statements. A first 

statement type includes statements that are wholly independent of the underlying control 
language form. A second statement type includes underlying control language form itself, 
plus extensions to that form, making the form more flexible. Typically, the underlying 
language form will be completed in ladder logic. The second statement type is particularly 
useful where automated electronic editors are used to compile a template based machine tree, 
thus generating a control program in the underlying control language form. Each statement 
type will be explained separately. 

[00744] Statements Independent of the Underlyin£ Control Language Form 

Referring again to Figure 16, a typical set of templates used to provide a program for 
machine 1610 have a template type corresponding to each machine tree control-task type. 
For example, a template set for machine 1610 would include machine, indexer, station, 
workunit, axis and control panel templates. In addition, the set would include other more 
detailed templates to further define each of the aforementioned templates. A template is a 
model program unit available for repeated use as a pattern for many modules based thereon. 
[00745] Referring to Figure 17, a typical template includes a template type designation 

and may include a name field which must be filled each time a template is used so that the 
specific instance of the template can be differentiated from other modules, including other 
instances of the same template. 
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[00746] In addition, each template 1794 may include LL logic sections 1795 having 

one or more rungs of LL logic. The idea here is that for each specific template type 1794 
used to represent a specific control-task type in a machine tree 1611, there will often be some 
logic, albeit in many cases minimal, that is always required for the specific control-task type. 
For example, for safety purposes, a master control panel will always include ON-OFF means 
for turning the machine on and off Thus, every machine template will require ON-OFF LL 
logic and an LL logic section 1795 will provide the universally required logic. 
[00747] Each template 1794 may also include child module specification sections 

1796. The contents of the child module specification section 1796 represents one type of 
language statement that is wholly separate from the underlying control language form. In the 
child ID section 1796, the template provides an area where a user can define module 
specifications that designate other modules required to further define the designating module. 

[00748] The relationship between a designating module and a designated module is a 

parent/child relationship wherein the designating module is the parent and the designated 
module is the child. For example, a machine module for machine tree 1611 would include a 
module specification designating an indexer module 1620. Similarly, in the present example, 
the machine module would include two separate module specifications to separately specify a 
"master control panel" module and an axis module named "air" which further detail the main 
control panel 1658 and the air axis 1686, respectively. The "master control panel", "air" and 
"Tl" modules would all be child modules of the parent machine module. 
[00749] Continuing, the indexer 1620 module would include a child module 

specification designating five separate station modules, one for each of the five stations, 
1630-1635, as well as a module specification designating an axis module named "transfer" to 
control the transfer bar 1620. 

[00750] The fourth station module 1634 would include a first module specification to a 

workunit module named "horizontal mill" and a second module specification to specify an 
axis module named "clamp". The clamp module would detail logic for controlling clamp 
1644 by either including complete LL logic or designating other modules that would 
complete LL logic for clamp control. 

[0075 1] The work unit module named "horizontal mill" would specify axis modules 

named "spindle", "main slide" and "cross slide" as well as a control panel module to define 
control panel 1657. Similarly, each of the other station and work-unit modules would specify 
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other modules until every control-task in the entire industrial process has been completely 
defined and reflected in a template-based tree, mirroring machine tree 1611. 
[00752] Referring to Figure 1800, the machine tree 1811 expands even further, each 

axis comprising a number of different control-tasks and corresponding modules. In Figure 
1800, only the main slide axis 1802 associated with the horizontal mill 1822 is shown. 
However, it should be understood that tree branches, like branch 1800 in Figure 18, must be 
provided for each axis and each control panel. While the control panel branches will include 
modules based on templates that are different than the templates required to specify an axis, 
the process of populating modules with required lists to define parent modules is the same. 
Figure 18 will be explained in detail below. 

[00753] Moving down the machine tree, modules associated with lower tree control- 

tasks generally include an increasingly larger relative section of control logic. At the 
extreme, the final modules at the distal lower ends of the tree consist entirely of control logic 
and have no child specification sections. Surprisingly, only a few dozen templates are 
required to provide modules that completely describe an industrial process. When compiled, 
so that LL logic sections in child modules are plugged into their designating parent modules, 
a complete LL logic program can be provided. 

[00754] The preferred template language includes different kinds of module 

specifications that can be used to accommodate different circumstances. For example, one 
type of module specification is a module "list" which allows zero or more component 
modules of a specific type (i.e. associated with a specific template). Referring again to 
Figure 1600, an indexer module may include a module list called "station" which includes 
specifications to five modules, one for each of the five machine stations 1630-1635. In this 
way, a single module specification can reference five station modules. Each station module 
in the list must be assigned a unique job specific name to ensure that it can be different from 
other modules designated in a common list specification. In the example here, the stations 
and, hence station modules, are referred to as 1630-1635. 

[00755] Yet another kind of module specification is an "optional" module specification 

which results in either no instances or exactly one instance of the designated type. For 
example, a preferred indexer template includes an optional module specification for an 
indexer control panel. While it is not necessary to have an indexer control panel, where a 
machine line is unusually long, it is often advantageous to include an indexer control panel 
somewhere along the line to allow local indexer control. The optional module specification 
gives a programmer the option, based on job specific requirements (i.e. the length of a 
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machine line), to provide LL logic for an indexer control panel when one is desired. In the 
present example, the indexer does not include a control panel and, therefore, no module 
would be created. 

[00756] Another module specification kind is a "renameable" module specification 

which results in a single named component module of a designated type, but will also allow a 
job-specific name to override the default name. Another kind of module specification is a 
"fixed" specification. Here, the template designated by the specification does not result in a 
child module. When compiled, fixed templates simply expand into the designating modules. 
Fixed specifications are not named. 

[00757] Another kind of module specification is a "named" module specification 

which results in a single, named component module of the type identified in the specification. 
For example, for safety purposes, all machines require a master control panel. Thus, a 
preferred machine template includes a named module specification called "master control 
panel" which identifies a single instance of a master control panel template. 
[00758] One final kind of module specification is a "choice" specification which makes 

a selection from a list of mutually exclusive module types based on job specific information. 
For example, while a control panel requires some type of interactive device for a user to turn 
a machine on or off, a user may prefer either a push button or a selector switch. To this end, 
in a control panel template, a choice specification is provided which includes two fixed 
module specifications, one for a push button and another for a selector switch. Like a fixed 
module specification, the template associated with a chosen type is simply expanded when 
the machine tree is compiled (i.e. no module results from a choice specification). 
[00759] A second type of language statement wholly separate from the standard LL 

rung form includes data definitions. Data definitions are common in programming language 
and should be familiar to a person of ordinary skill in the art. Therefore, data definitions will 
not be explained here in detail. Suffice it to say however, that in template language, data 
definitions are required to declare and reserve space for all PLC data table types such as 
inputs, outputs, timers, counters, etc., and allows the association of attributes with each 
declaration. 

[00760] Extensions to the Underlying Control Language Form (LL) 

While some logic is always the same for a specific machine tree control-task type, 
other logic is job-specific and distinct to an associated given module and would be extremely 
difficult to furnish in prewritten LL or other template sections. For example, one typical 
prerequisite for turning on a machine 1610 to begin an industrial process is that all local 
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control panels (i.e. control panels other than the master control panel) be in remote mode 
often called "automatic". Remote mode means that a control panel forfeits control over the 
local machine section to an operator panel located higher up in the machine tree, for instance 
the master control panel. Local mode (e.g. "manual"), disables the parent operator panel and 
permits only local control of a section of the machine. Thus, one LL logic rung called "all 
child nodes remote" in a main control panel module should include a series of contacts, one 
contact for each local control panel. Each local control panel module would include a coil 
corresponding to its contact in the "all child nodes remote" rung. When the local control 
panel is in remote mode, the local panel module coil would be energized, thus closing the 
corresponding contact in the "all child nodes remote" rung. Thus, a coil at the end of the "all 
child nodes remote" rung would indicate when all local panels are in automatic or remote 
mode allowing the machine 1610 to be turned on. 

[00761] Prior to designing a machine there is no way of knowing how many local 

control panels will be required. One machine may not require any local control panels while 
another machine may require ten or more local control panels. The number of local control 
panels required for a machine is job-specific. This means that prior to designing a machine 
1610, there is no way to determine the number of contacts required in the "all child nodes 
remote" rung in a main control panel module. Unfortunately, standard LL rung forms do not 
allow for variable numbers of contacts and, therefore, cannot adjust to job-specific 
requirements. While a programmer could alter the form of an "all child nodes remote" rung 
while manually programming using templates, when the programmer is using automated 
editors there is presently no easy way to change rung form to accommodate job-specific 
parameters. 

[00762] To overcome this limitation, the template language includes both macro 

instructions and a symbolic expression language that are extensions to the standard LL rung 
form itself. One macro instruction is an "AND list" instruction which provides a mechanism 
by which variable numbers of series contacts can be provided in an LL rung. The number of 
contacts can be tied to job specific requirements. For example, where four local control 
panels are required in an "all child nodes remote" rung, the "AND list" macro would provide 
four contacts, one for each local panel. In the alternative, where ten local panels are provided 
the "AND list" macro would provide ten contacts, one for each local panel. 
[00763] The symbolic expression language is used with the macro instructions to 

designate macro operands. The symbolic expressions include single characters that may be 
concatenated with template-authored symbolic names (defined using Data Definition 
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statements) to form reusable operand specifiers. These symbolic expressions may be used by 
placing them above LL instructions in an LL rung. A preferred set of symbols consists of 
three path specifiers and two separators. 

[00764] Path specifiers indicate where relevant operand definitions can be found. 

Separators allow concatenation of more path information such as the name of a specific child 
module, data item, or attribute. A first path specifier is the symbol "$". Specifier "$" 
indicates the name of the module that the specifier appears in. For example, if specifier "$" 
appeared in the master control panel module, the specifier would provide a path to the master 
control panel module. In addition, the specifier would also provide partial paths to all main 
control panel child modules. 

[00765] A second path specifier is symbol "#". Symbol "#" indicates the instance of a 

particular member of a list. A third path specifier is symbol MA " which may be followed by a 
template type name. Symbol ,IA " represents the first ancestor (i.e. parent, grandparent ...) 
module whose type matches the type designated after the symbol. 

[00766] A first separator is symbol Symbol "." indicates that the text following is 

the symbolic name of a child module or data definition within the program unit designated by 
the path specifier preceding the separator. A second separator is symbol " indicating that the 
text following it is the symbolic name of an attribute associated with the entity designated by 
the path specifier preceding the separator. For the purposes of this explanation, attributes will 
include module list names. 

[00767] Referring to Figure 19, a standard "all child nodes remote" LL rung 1925 that 

might appear in master control panel logic is illustrated. The rung 1925 includes three 
contacts MACHINE.LP1 .AUTO, MACHIINE.LP2.AUTO and MACHINE.LP3.AUTO and a 
single coil named MACHINE. ALL CHILD NODES REMOTE. Each of the three contacts 
"MACHINE.LP1 .AUTO", MACHINE.LP2,AUTO", and "MACHINE.LP3 .AUTO" 
corresponds to a separate local control panel (not shown). 

[00768] Referring also to Figure 20, the symbolic expression language described above 

can be combined with an "AND list" macro to provide an LL rung 2027 that can expand into 
rung 1925 having three contacts when compiled. An AND list macro 2028 and a single "all 
child nodes remote" coil make up rung 2027. The "AND list" macro 2028 includes symbol 
"$" which specifies a path to the present module. The " indicates that the symbolic name 
"LPS" that follows is an attribute associated with the present module. In this case "LPS" is a 
module list associated with the main control panel module. Thus, the expression "$" 
represents a module list in the main control panel module. The module list provides operands 
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to the "AND list" macro. The "AND list" macro 2028 includes the condition "Auto" with the 
path specifier "#". Specifier "#" indicates that the "Auto" condition should be concatenated 
with the operands above the "AND list" command. 

[00769] When compiled by an automated compiler (or by hand), the "AND list" macro 

2028 expands into series contacts, one contact for each reference in the module list "LPS." 
For example, assuming the module list "LPS" included a job-specific membership of three 
instances name "LP1," "LP2" and "LP3," rung 2027 would expand into rung 1925. Similarly, 
if the module list "LPS" included a job-specific membership of ten instances, rung 2027 
would expand into a rung having ten series contacts, each contact named for a different one 
of the ten instances in the list. Thus, using the symbolic expression language in conjunction 
with the "AND list" macro, the number of series contacts can vary, depending upon job- 
specific parameters. 

[00770] A second macro instruction is an "OR list" instruction. The "OR list", like the 

"AND list", when combined with the symbolic expression language, provides for variable 
rung forms, depending upon job-specific parameters. However, instead of providing series 
contacts, the "OR list" macro provides variable numbers of parallel contacts. An exemplary 
rung 2130 including an OR list macro 2131 is illustrated in Figure 21. "SRequests" specifies 
a module list named "Coil Requests" having a job-specific membership. Each instance in the 
"Coil Requests" list is to be concatenated with a coil request name and all instances are to be 
placed in parallel in rung 2130 when the rung 2130 is compiled. Therefore, if module list 
"Coil Requests" includes three job-specific instances, three parallel contacts (one contact 
named for each instance) will replace the "OR list" macro 2131 when compiled. If the 
module list "Coil Requests" includes ten job-specific instances, the "OR list" macro 2131 
would be replaced by ten, uniquely named parallel contacts. 

[00771] The "OR" and "AND list" macros are extremely powerful and add a level of 

flexibility to programming in the template language that cannot be provided using the 
standard LL rung form. Using the macros in conjunction with the symbolic expression 
language facilitates templates that refer to variable job-specific parameters and to data items 
defined in other modules by associated templates even before the job specific parameters and 
data items are defined. 

[00772] In addition to the macros and symbolic expression language, there is one other 

type of extension to the standard LL rung form itself called pseudoinstructions. 
Pseudoinstructions take three forms: XPC, XPO and OTX which correspond to standard XIC 
(examine if closed), XIO (examine if open) and OTE (output enable) LL instructions. XPC 
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and XPO stand for examine predicate closed and examine predicate open, respectively. OTX 
stands for output expansion. 

[00773] One of the problems with any LL programming shortcut based on a modular 

library of LL logic components is that logic must be provided to accommodate all possible 
requirements. Therefore, in many cases logic that is not required in a specific application 
will be provided to cover general requirements. Moreover, sometimes logic required in 
general applications are not permitted in specific applications. 

[00774] For example, typically there is less danger associated with movements in a 

cycle's second half than with movements in the first half and therefore, a reduced set of 
conditions may be provided for second half-cycle movements than for first half-cycle 
movements. The first half-cycle includes movements that shift the mill spindle toward or into 
a workpiece. The second half-cycle includes movements that shift the spindle out of and 
away from the workpiece. Prior to any axis movement there is typically a set of conditions 
that must be met to ensure a safe move. Therefore, a reduced set of conditions can apply to 
second half-cycle movements, the reduced set reflecting the reduced possibility of danger. 
[00775] The preferred template set includes only one template type corresponding to 

axis movement. Therefore, the axis movement template must include logic for both the full 
set of conditions used in the case of a first half-cycle movement and the reduced set of 
conditions used in the case of a second half-cycle movement. Referring to Figure 22, a 
required full set of conditions will show up in an LL logic rung 2234 as a full set 2233 of 
series-connected contacts C1-C5. When all of the conditions are met, all of the contacts Cl- 
C5 are closed and an associated output coil OUT is energized, indicating that an associated 
axis movement can begin. 

[00776] The reduced set of conditions corresponding to the second half-cycle shows up 

in LL logic as a branch 2235 parallel to the full set 2233 of contacts, the branch including a 
reduced set of contacts C6, C7; one contact for each condition in the reduced condition set. 
Thus, the axis movement template provides LL logic 2233, 2235 for movements in both the 
first and second half-cycles. While both the full and reduced logic sets may be applicable to 
movement in the second half-cycle, they are not both applicable to movements in the first 
half-cycle. In other words, if an axis movement module corresponds to a first half-cycle 
movement, branch 2235 including the reduced logic set is not permitted, but branch 2235 is 
required for a second half-cycle movement. 

[00777] XPC and XPO pseudoinstructions are used to examine compile time constants 

representing configuration options such as the ones shown in Figure 22. The effect of the 
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evaluation will be either a short or an open circuit in the generated program, depending on 
evaluation result. For instance, the result of an XPC on a true condition is a short circuit 
while the result of an XPO on a true condition is an open circuit. In Figure 22, an XPC 
contact 2236 identifying a second half-function is provided in series with the logic of branch 
2235. The XPC contact 2236 shorts when rung 2234 is associated with a second half-cycle 
movement and is an open circuit when rung 2234 is associated with a first half-cycle 
movement. Therefore, upon compiling, the XPC contact 2236 leaves branch 2235 in rung 
2234 when a corresponding movement is in a second half-cycle and removes branch 2235 
when a corresponding movement is in the first half-cycle. 

[00778] A side effect of the compile time evaluation of pseudoinstructions can be 

further optimization of the generated logic. For instance, an open circuit in series with other 
input instructions renders the other instructions unnecessary. A branch that is shorted renders 
parallel branches unnecessary. With the XPO and XPC instructions, unnecessary instructions 
can be removed from their associated circuits without changing the meaning of the circuit. 
Upon compilation, optimization can ripple recursively through a program, potentially causing 
entire rungs, including coils, to be discarded. 

[00779] Template language allows expression and encapsulation of that, and only that, 

which is universally true of a particular machine component or operating characteristic. A 
side effect of this is that the granularity of some of the templates can be very fine. This 
means that the topology of some of the circuits after expansion can be very inefficient. For 
example, referring to Figure 22, the redundant branch 2233 including contacts C1-C5 would 
be produced for second half functions. To rectify this, the OTX pseudoinstruction enables 
the template author to instruct the compiler to optimize certain circuits. When the compiler 
encounters an XIC or XIO instruction whose contact is an OTX coil, it will replace the 
instruction with an in-line expansion of the actual contents of the rung associated with the 
OTX coil. 

[00780] For example, referring to Figure 22-1, a first LL rung 2220 includes contacts 

A and B and an OTX coil C. A second LL rung 2222 includes contacts C and D and other 
"stuff where contact C corresponds to the OTX coil C. When compiled, coils A and B 
corresponding to OTX coil C are expanded into the coil in branch 2222 yielding branch 2224 
as shown in Figure 22-2. This provides the template author with a large degree of control 
over the resulting topology of the generated circuits. 

[00781] Referring now to Figures 23-35 an exemplary set of templates is provided 

which can be used to better understand template language generally. The preferred template 
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group is a subset of a template set specifically designed for the metal-removal industry. 
Referring to Figure 23, a machine template 2398 includes the template type designation 
"machine" and a blank name field 2399 that has to be filled in to identify a specific machine 
module. The machine template 2398 itself does not directly include LL logic and hence, has 
no LL logic section. Instead, the machine template has a child module specification section 
2396a including several module specifications including a named module specification called 
"master control panel" 2300 and both axis- and indexer- list module specifications 2302, 
2304, respectively. Because each machine must include at least one control panel for safety 
purposes, every machine template (and hence every machine module) must include a master 
control panel specification 2300. 

[00782] Referring to Figure 24, a master control panel template 2406 includes an LL 

logic section 2494b required for start and stop push buttons. The logic in section 2494b is 
universally required for all master control panels. In addition, the master control panel 
template 2406 includes a child module specification section 2496b that references other 
modules using module specifications. The modules designated in the child module 
specification section 2496b may be required to completely provide LL logic to control the 
master control panel 2458. Whether or not modules must be designated in the child ID 
section 2496b depends on job specific requirements. Note that named module specification 
"remote cycle enabler" and fixed module specification "operator panel" are required attributes 
of any master control panel module. 

[00783] Referring again to Figure 23, the module list named "axis" 2302 includes a list 

of all machine- wide axes. In the present example, the "air" axis is the only machine-wide 
axis and therefore, the axis-module list specification would include only a single specification 
called "air". Referring to Figure 25, an axis template 2508 includes an axis template 
designation, a name field 2510, and a child module specification section 2596c having three 
separate module specifications for switch packet, trajectory and actuator, all of which have to 
be detailed to completely define an axis. 

[00784] Referring again to Figure 23, the indexer module list specification 2304 

includes a list of indexer modules, one for each machine indexer. In the present example, 
there is only a single indexer Tl and, therefore, only one indexer entry, identifying indexer 
module Tl, would appear in the indexer list specification. Referring to Figure 26, an indexer 
module includes an indexer template designation, name field 2614, and a child module 
specification section 2696d. The module ID section 2696d includes an optional module 
specification 2616 for a control panel and two module list specifications, one for axis 2618 
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and another for station 2620. In the present example, because there is no indexer control 
panel, the optional control panel would not be designated. Because we have one indexer axis 
(i.e. "transfer"), there would be one specification in the axis module list specification 2618 
named "transfer". In addition, because there are five stations, there would be five 
specifications in the station module list specification 2620. Each station designated in 
module list 2620 would identify a different station module corresponding to a different one of 
the five stations S1S5. 

[00785] Referring now to Figure 27, the station template 2722 is nearly identical to the 

indexer template 2712 of Figure 27, except that, instead of having a station module list 
specification, the station template 2722 includes a work-unit module list specification 2724. 
In the present example, there would be five separate station modules like the one in Figure 
27, each module identified by a different name in the name field 2725 and corresponding to a 
like-named station in the station module list 2720 of the indexer module named "Tl". 
[00786] Referring now to Figure 28, a work-unit template 2826 includes a work-unit 

designation, a name field 2828, and a child module specification section 2896e having only 
two module specifications, an optional operator panel module specification 2830, and an axis 
module list specification 2832 identifying all axes associated with a work-unit. In the present 
example, because the horizontal mill 2822 includes three axes (spindle, main slide, and cross 
slide), three separate specifications would be included in the axis module list specification 
2832 identifying three separate and distinctly named axis templates. In addition, because the 
horizontal mill 2822 includes a local control panel 2857, the optional operator panel module 
specification would be designated. 

[00787] The templates in Figures 37-43, represent all of the templates required to 

completely specify an axis. To specify an axis, it is necessary to define all positions 
associated with an axis and switches that indicate positions. The switches act as controller 
inputs for the axis. In addition, it is necessary to define possible axis-movement requests, 
herein referred to as trajectories. Moreover, it is also necessary to define actuators used to 
effect trajectories and how a controller will communicate with the actuators (i.e. coils and 
coil requests). Coils and coil requests act as controller outputs to the actuators. 
[00788] Referring also to Figure 18, a template-based tree branch 1800 for one axis, 

the main slide axis of the horizontal mill, is illustrated showing the hierarchical relationship 
between modules required to define the main slide axis. Referring also to Figure 25, to 
accommodate all the information required to specify an axis, the axis template 2508 includes 
a child ED section 2596c having a named "switch package" module specification 2591a and 
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sections 2591b and 2591c for trajectory and actuator module list specifications, respectively. 
Therefore, in module list specification 2591b, the trajectory list would only include two 
specifications, one for "advance" and one for "return". In Figure 18, the "advance" and 
"return" trajectories are shown as child modules 1804 and 1806. 

[00789] Referring still to Figure 25, the main slide subassembly includes only a single 

motor, which is the main slide actuator. Therefore, only one actuator "motor" will be 
designated in the actuator module list specification 2591c. In Figure 18, the main slide 
actuator is shown as child module 1808. Switch package module 1810 is also a child module 
of main slide axis module 1802. Referring also to Figure 37, the switch package template 
3793 includes child ID section 3796f having two module list specifications 3794 and 3795. 
A "limit switch" module list specification 3794 is used to specify axis switches. The main 
slide axis includes advanced switch 3739 and returned switch. Thus, switch module list 
specification 3794 would specify two switches as switch package child modules named 
"advanced LS" and "returned LS." 

[00790] The two switches define three main slide positions named "advanced," 

"intermediate" and "returned." Therefore, position module list specification 3795 would 
specify three positions as switch package child modules named "advanced," "intermediate," 
and "returned." Referring to Figures 37 and 38, a position template 3803 is used to provide a 
position module for each position designated in position list section 3795. Each position 
template 3802 includes a name field 3801 for identifying the specific position modules (i.e. in 
the present case "advanced", "intermediate" and "returned"). In addition, each position 
template 3803 includes four separate module list specifications 3804a, 3804b, 3804c and 
3804d corresponding to two possible types of limit switches and two possible states of each 
type of switch (i.e., normally open (NO) tripped, NO released, normally closed (NC) tripped, 
and NC released). 

[00791] Each of the lists 3804a, 3804b, 3804c and 3804d is populated with switches 

from switch module list specification 3894 that are in a corresponding state (i.e., tripped or 
released). For example, when a main slide subassembly is in the advanced position, the 
advanced switch is tripped and the returned switch is released. Assuming both switches are 
wired normally open (NO), the advanced switch would be listed in the NO tripped LS module 
list specification 3804a while the returned switch would be listed in the NO released LS 
module list specification 3804b (in this case no switches would be listed in module list 
specifications 3804c and 3804d). Referring again to Figure 18, the NO tripped advanced 
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switch and NO released returned switch are shown as child modules 1816 and 1817 for the 
position module 1813 named "advanced." 

[00792] Similarly, position templates for the "intermediate" and "returned" positions 

would be populated with appropriate switches. In Figure 18 intermediate position module 
1814 has two child modules, "NO released advanced LS" 1818 and "NO released returned 
LS" 1819 while returned position module 1815 has child modules "NO released advanced 
LS" 1820 and "NO tripped returned LS" 1821. 

[00793] Referring to Figures 25 and 39, a trajectory template would have to be 

designated and populated for each axis trajectory (i.e., each movement request). For the 
horizontal mill main slide, there are two trajectories, "advance" and "return". Therefore, 
there would be two trajectory modules, one named "advance" and a second named "return" 
which are shown as child modules 1804 and 1806, respectively, in Figure 18. 
[00794] Each trajectory can be divided into various moves. A simple single speed 

linear trajectory includes three moves. An "initial" move begins trajectory motion followed 
by an "intermediate" move between two positions, the trajectory ending with a "final" move 
that stops the motion. Thus, referring still to Figure 39, the trajectory template 3909 includes 
a child module specification section 3996g for a move module list specification. Referring 
also to Figure 18, the "advance" trajectory module 1804 includes "initial" 1822, 
"intermediate" 1823 and "final" 1824 move child modules. The "return" trajectory 1806 
includes similar child modules 1825, 1826, 1827. 

[00795] Referring to Figure 40, a move module based on move template 4016 must be 

provided for each move in child module specification section 4096h. Each move template 
4016 includes a child module specification section 4096h for a coil request module list 
specification. A coil request is a request to a specific coil to actuate an actuator (e.g. motor) 
when a specific position associated with a move has been reached. For example, on a two 
speed motor, one coil may drive the motor at one speed to facilitate one move. A second 
sequential move, however, may require excitement of two coils to activate two motors to 
achieve a greater speed once an intermediate position has been reached. Thus, a single move 
may require two or more different coil requests. A coil request module based on the coil 
request template shown in Figure 41 must be provided for each coil request designated in the 
child module specification section 4096h of a move module. 

[00796] Referring to Figures 25 and 42, for each actuator designated in actuator 

module list specification 2591c, an actuator module based on actuator template 4218 must be 
provided. Each actuator module must be named to distinguish specific modules. The 
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actuator template 4218 includes a child module specification section 4296i for designating a 
coil module list specification 4219. A coil is an output to drive a motor or the like. Referring 
also to Figure 18, for the horizontal mill main slide there are only two coils, a "work" coil and 
a "home" coil shown as child modules 1828 and 1829. Referring to Figure 43, a coil module 
based on coil template 1821 must be provided for each coil module designated in a 
specification 1819. 

[00797] Once all the trajectories, actuator, limit switches, positions, moves, coil 

requests, and coils have been identified and associated module list specifications have been 
populated and required modules have been provided, the tree branch and corresponding LL 
logic required to completely control the axis has been designated. Modules based on all of 
the templates illustrated in Figures 37-43 are required to define each axis. 
[00798] C. Function Contingencies 

Using a complete template set it should be fairly easy for one skilled in the art to 
construct a complete template-based machine tree using the template set. However, at least 
one template-based programming aspect is not entirely intuitive based upon a perusal of the 
complete template set. This complex template programming aspect is how the function 
template 4936 in Figures 49A and 49B which controls function performance is to be used. 
[00799] Function performance must be limited by the instantaneous characteristics of 

other functions in the same cycle. These instantaneous characteristics can be gleaned from a 
bar chart. For the purposes of referring to various functions in this explanation, where one 
function is observed from the perspective of another function, the function observed will be 
referred to as an observed function and the other function will be referred to as the observing 
function. 

[00800] Four separate relationships exist between any two of the four functions, (or, 

more precisely, between the action of the observing function and the done condition of the 
observed function). A first relationship is a "stable/unstable" relationship. Stable simply 
means that an observed function does not start or stop during an observing function. A 
second relationship is a "cancel by other/cancel by me" relationship. Where an observed 
function is unstable from the perspective of an observing function, the state of the observed 
function is changed either by the observing function or by some other condition. When the 
observing function changes the observed function state, the observed function is said to be 
canceled by the observing function. From the perspective of the observing function, the 
second function is categorized as "canceled by me". When some condition other than the 
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observing function changes the observed function state, from the observing function 
perspective, the observed function is "canceled by other". 

[00801] A third relationship is a "my half-cycle/other half relationship. "My half- 

cycle" means that an observed function starts before an observing function in the observing 
function's half of a cycle. "Other half means that the observed function is either in the 
opposite half-cycle as the observing function or, if both observing and observed functions are 
in the same half-cycle, the observed function starts after the observing function. 
[00802] The fourth relationship is a "position/latch" relationship. This relationship 

deals with the nature of the observed function itself. A function can have one of three 
different natures, position, latch or a combination of both. Functions of the position nature 
will end when a specific axis position is reached. 

[00803] Referring now to Figure 50, an attributes table 5031 is illustrated that includes 

an attributes column 5032, twelve "bucket" columns A-L, and a list of the possible function 
attributes described above. A user can employ this table 43 1 to categorize, from the 
perspective of an observing function, all other observed functions in a cycle into one of the 
twelve buckets A-L. For example when function Bl is the observing function, observed 
function B2 is a stable, other half, position function which places function B2 in bucket J. 
Similarly, with function Bl observing, observed functions B3 and B4 would be placed in 
bucket J. 

[00804] With function B2 observing, observed function Bl is a stable, my half of 

cycle, position function which places function Bl in bucket L With function B2 observing, 
both observed functions B3 and B4 go in bucket J. With function B3 observing, observed 
functions Bl and B2 are stable, other half, position functions placed in bucket J while 
observed function B4 is an unstable, canceled by me, other half, position function placed in 
bucket F. With function B4 observing, functions Bl and B2 go in bucket J while function B3 
is a stable, my half-cycle, position function in bucket L Note that with function B4 
observing, function B3 is considered "stable" because the cutter clear position CCP, once 
achieved, is not reversed until after function B4 has been completed. 
[00805] For every function B1-B4, there is an inverse function in an opposite half- 

cycle that is stable and is a position. For example, function B3 is the inverse of function Bl 
while function B2 is the inverse of function B4. Thus, all cycle functions can be divided into 
two groups, a first group being the inverse of the other. Gathering information about both 
function groups requires duplicative effort. Therefore, when defining a function by its 
relationships with other cycle functions, only a function corresponding to the first group, or, 



-170- 



in the alternative, the second group, is required. When bucketing functions with function Bl 
observing, a user would work backwards through the cycle bucketing functions until a 
duplicative function is encountered. Working back, as explained above, observed function 
B4 would be placed in bucket J. Observed function B3, however, is the inverse of function 
Bl and therefore represents duplicative information. Here, because function B3 is the inverse 
of function Bl, B3 could not possibly be performed during Bl and therefore, B3 need not be 
bucketed. As for function B2 information, that information is reflected in the bucketing of 
function B4 and is not needed. 

[00806] Thus, for each function in a cycle, only one other function would be bucketed 

(i.e. B4 bucketed for Bl, B3 for B4, B2 for Bl, and Bl for B2). Obviously, the present 
example is extremely simple. However, one of ordinary skill in the art should easily be able 
to apply these teachings to bucket functions for complex cycles. 

[00807] In addition to instantaneous characteristics of other functions in the same 

cycle, commencement and continuance of a function is also contingent upon three other 
conditions. A first condition is that a function will not start in an automatic sequencing mode 
of operation unless it is in its start position. A second contingency is that a function will not 
start in a manual discrete stepping mode of operation until all required control buttons have 
been triggered by a user. A third contingency is that a function will not start in any operating 
mode unless prescribed safety requirements are met. 

[00808] Referring again to Figure 50, the attributes column 5032 includes attributes 

"my start position 11 , "push button", and "safety" corresponding to each of the three 
contingencies identified above. Three additional bucket columns M-O are provided, each 
column corresponding to a different one of the three conditions. Each instance of a condition 
is bucketed into an appropriate column, M-O. 

[00809] Referring to Figures 49A and 50, after all functions and contingencies that 

must be bucketed have been bucketed according to attributes table 5031, they can be used to 
populate lists in a module list specification section 2342. The list specification section 2342 
includes one module list specification for each bucket A-O in table 5031. Each module list 
should be populated with functions or other contingencies corresponding to the list name. 
[00810] Referring to Figure 49A, the function template 2336 also includes a plurality 

of "AND list" macros 234A-2340, one macro corresponding to each module list specification 
in section 2342. When expanded, each "AND list" macro 2344A-2340 expands into a series- 
connected set of contacts, one contact for each member in an associated module list 
specification. The coils in series with the macro are excited only when each contact in the 
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series is true. Thus, coil "A" will not be excited unless all functions bucketed and placed in 
the "unstable, canceled by other, my half, position" module list specification 2348 are true. 
Similarly, coil "O" will not be excited unless all safeties in safety module list specification 
2346 are true. 

[0081 1] In addition to the instantaneous characteristics of other functions in the same 

cycle and the other contingencies identified above, function performance may also depend on 
the physical characteristics of an axis. Physical characteristics of an axis or an industrial 
process can put additional constraints on the manner in which a function can safely be 
performed. Functions can be divided into three types based on the kinds of constraints placed 
on them. 

[008 12] A first function type is a normal function. Normal functions can be performed 

either in forward or reverse directions without damaging a workpiece or an associated 
machine's components. Performing a function in reverse means making the axis move in the 
opposite direction of the trajectory related to the function. This may produce the same effect 
as, but in terms of function logic is not the same as, performing the functions inverse 
function. 

[008 13] A second function type is a non-reversible function meaning that, after the 

function has been performed in whole or in part, in the forward direction, it cannot be 
reversed and performed in the other direction. An example of a non-reversible function is a 
transfer bar forward movement function which cannot be reversed once it has started forward 
as it might cause damage to work pieces or a fixture's axis components. 
[00814] The third function type is a non-repeatable function. A non-repeatable 

function cannot be started forward a second time once it has been performed to completion. 
For example, where an axis device places a pin in a hole while performing a function, after 
the function is performed, the function cannot again be performed because the hole is already 
blocked by the first pin. Hence, the function is non-repeatable. 

[00815] To accommodate the three separate function types (i.e. normal, non-reversible 

and non-repeating), template 2336 includes a choice module specification 438 having 
"normal function mapping" 2339, "non-reversible function mapping" 440 and "non- 
repeatable function mapping" 2341 specifications. Depending upon function types, a user 
would choose one of said specifications 2339-2341 and provide an associated mapping 
module. 
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[00816] The only other function characteristic that must be determined to completely 

define the function template 2336 is to specify in which half-cycle a function occurs, first or 

second. Cycle half specification is required for contact 2350 in Figure 49B. 

[00817] After all of the module specifications have been designated for the function 

template 49A, 49B, the user is done programming control of the specific function. Referring 

to Figures 49 A and 51 when normal function mapping is chosen in template 5136, the 

bucketed functions and conditions from table 5031 are mapped into mapping coils 5149 

according to a normal function mapping template 5151. Similarly, where the non-reversible 

or non-repeating mapping choices are made in template 2336, other mapping templates are 

used to map bucketed functions and conditions slightly differently. Thus, using a template 

set, function performance can be made contingent upon axis physical characteristics, 

instantaneous characteristics of functions sharing a cycle, the state of a cycle itself, the state 

of any control means associated with the function, and whether or not job-specific safeties 

associated with a function have been met. 1 

[00818] D. Editors 

In addition to providing truly reusable subsets of control logic, a template set makes 
automated programming possible wherein programming editors mirror the diagraming 
conventions which are already widely used in industrial control programming. 
[00819] The editors allow a user to construct images that are similar to conventional 

diagrams and documentation. During image construction, the editors use information from 
the images to create modules and populate specifications in existing modules. After a user 
has used the editors to describe all aspects of a machine, all required modules have been 
populated and a complete template-based machine tree is formed in editor memory. Then, a 
computer is used to compile the machine tree and provide required LL control logic. 
Referring to Figure 29, the four editors are referred to herein as a machine editor 2962a, an 
axis editor 2962b, a control panel editor 2962c, and a bar chart editor 2962d. 
[00820] In addition to imitating traditional diagrams, each of the editors has been 

designed to incorporate conventional computer interface features that most programmers 
should already be comfortable using. Conventional features include an interactive computer 
terminal that presents programming options in pull down menu form and allows option 
selection using a mouse or other similar selection means. 
[00821] 1. Machine Editor 

The machine editor 2962a allows a user to build a floor plan image directly on a 
computer monitor. During image construction, the machine editor 2962a constructs a 
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template-based machine tree reflecting the floor plan image. In addition, while a user is 
constructing a template-based tree, the editor 2962a is simultaneously gleaning information 
from the tree and either creating new template-based modules or populating existing modules 
so as to provide a template-based tree specification. 

[00822] The machine editor 2962a only facilitates construction of the floor plan and 

the portion of a machine tree corresponding thereto. The machine editor 2962a cannot 
specify specific aspects of an axis, an operator panel, or a sequence of events. Specification 
of these more detailed aspects of a machine are reserved for the axis 2962b, control panel 
2962c, and bar chart 2962d editors, respectively. As depicted in Figure 29, the machine 
editor 2962a accesses the other special editors when specific detail is required. 
[00823] Referring now to Figure 30, an initial machine editor image 3042 that is 

displayed on a monitor at the beginning of a programming session includes a menu bar 3044 
at the top of the image 3042 and a split screen having a tree section 3049 and a floor plan 
section 3050. The tree section 3049 provides an area wherein the editor 2962a visually 
displays a template machine tree as a corresponding floor plan is constructed. The floor plan 
section 3050 is where the floor plan itself is constructed. 

[00824] The menu bar 3044 includes two choices, FILE and EDIT. The FILE choice 

allows a user to store, retrieve, and delete files from memory. The FILE choice operates in a 
manner that should be familiar to an artisan of ordinary skill in the art and therefore will not 
be explained here in detail. The EDIT choice allows a user to simultaneously construct and 
edit both a floor plan in the floor plan section 3050 and a template-based tree in the tree 
section 3049. 

[00825] Initially, a single icon 3052 corresponding to a main control panel appears in 

the upper left-hand corner of the floor plan section 3050 and both a machine module 
reference and a master control panel reference appear in the upper left-hand comer of the tree 
section 3049. The master control panel reference is below the machine module reference and 
indented to show a hierarchical parent-child relationship. These initial entries are provided to 
a user because they are always required as designated in the templates. Every template-based 
tree must begin with a machine module and every machine must have a master control panel 
for safety purposes. The machine module reference corresponds to the entire floor plan as 
constructed in the floor plan section 3050. The master control panel module corresponds to 
the control panel icon 3052. 

[00826] Furthermore, to uniquely identify the machine, the editor 2962a initially 

provides a floating name box 3054 prompting the user to enter a machine name. The 
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machine name is used by the editor 2962a to identify the correct machine module for a given 
industrial process. In the example above, the process is named "AB1" and therefore, the 
machine module name is AB1 and AB1 is eventually placed at the top of the tree 
representation in tree section 3049 (see Figure 31). 

[00827] After entering the machine name, a user can start building a floor plan by 

selecting the EDIT choice from menu bar 3044. When EDIT is selected, the editor 2962a 
provides a menu of possible programming options for further detailing whatever item in the 
floor plan section 3050 is selected. At the beginning of a programming session, there are 
only two possible items that can be selected, the machine itself or the master control panel. 
To select the master control panel, the user would click on the master control panel icon 
3052. To select the machine, the user would click on an area of the floor plan section 3050 
that does not include an icon. Typically, a user would wait until near the end of a 
programming session to detail the master control panel because he would know more about 
the machine at that time. 

[00828] Referring now to Figure 31, with the machine selected for editing and the 

EDIT choice chosen, a pull-down menu 3156 appears providing options for editing the 
machine module AB1. Referring also to Figure 23, a machine template 2398 can only be 
edited by adding to or subtracting from the axis 2302 or indexer 2304 module list 
specification. Therefore, the pull-down menu 3156 includes the only four possible machine 
module options: ADD INDEXER, ADD AXIS, DELETE INDEXER, and DELETE AXIS. 
(Delete options are only provided after an axis or indexer has already been added.) Referring 
also to Figure 16, in the present example, because the machine requires a single directly- 
connected axis, the user would select ADD AXIS from the menu 3156. Because each axis 
requires a unique name, after selecting ADD AXIS, the editor 2962a would request a name 
for the new axis using a floating name box (not shown). 

[00829] In the present case, a user would enter "air" as the name of the axis. Then, the 

editor 2962a would provide an axis module reference named "air" below the AB1 module 
reference in the tree section 3149 and would also provide an air axis icon 3158a next to the 
master control panel icon 3152 in the floor plan section 3150. The "air" module reference, 
like the master control panel reference, will be indented from the AB1 module reference to 
show a parent/child relationship. 

[00830] While the editor 2962a is forming the floor plan in floor plan section 3150, the 

editor 2962a is also creating modules and populating existing module specifications. 
Referring to Figure 32, the method 3243 of creating and populating begins at process block 
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3245 where the editor 2962a gleans new image information from the image. Where an "air" 
axis image has been added to the floor plan and named, the editor 2962a would identify a 
new axis designated "air". 

[0083 1] At decision block 3246 the editor 2962a determines if the new information 

requires an additional module. Where an additional module is required, at block 3247 the 
editor 2962a creates an additional module. Here, after the "air" axis has been named, the 
editor 2962a creates an axis module named "air". Next, at decision block 3248, the editor 
2962a determines if the newly-gleaned information is required to populate an existing 
module. If so, at block 3251 the editor 2962a populates the existing module. 
[00832] After the required modules have been created and existing modules populated, 

at block 3253 the editor 2962a determines if the image in section 3250 is complete. 
Typically image completion will be signaled when a user stores an image via the FILE option 
in menu bar 3144. When the image is complete, the editor 2962a exits process 3243. If the 
image is not complete, the editor 2962a cycles back to process block 3145 and continues to 
glean new image information used to create additional modules and populate existing 
modules. 

[00833] After the "air" axis has been added to the floor plan and named, the user again 

selects EDIT from the menu bar 3144, this time selecting the ADD INDEXER choice to add 
an indexer Tl. When ADD INDEXER is selected, because each indexer module requires a 
unique name, the editor 2962a would request an indexer name using another floating name 
box. 

[00834] After entering "Tl " to identify the indexer in the present example, the editor 

2962a would provide a "Tl" module reference below and indented from the AB1 module 
reference in the tree section 3149 and would also provide an indexer icon 3160 in the floor 
plan section 3150. Using the mouse the programmer could click on the indexer icon 3160 
and drag it into a desired position suitable for building the desired floor plan. In Figure 31, 
the indexer icon 3160 is shown in the right hand portion of the floor plan section 3150. 
Referring again to Figure 32, each time new information is added to the floor plan image, the 
editor 2962a follows process 3243 to create new modules and populate existing ones. 
[00835] If needed, a user can again select EDIT and add additional indexers and axes 

to provide a template-based machine tree and floor plan that corresponds to any machine 
configuration. For example, if a machine requires a source of pressurized coolant in addition 
to the air source, a coolant axis could be added to the machine module by again selecting 
ADD AXIS in the EDIT menu. In the present example, however, the machine includes only 
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one axis ("air"), one indexer ("Tl ") and the required master control panel. Thus, at this point, 
fundamental characteristics (i.e. axis, indexers, and control panel) of the machine module 
have been identified. 

[00836] Next, the user can further specify either the indexer "Tl" or the "air" axis. To 

further specify the indexer Tl, the user selects the indexer icon 3160 with the mouse and then 
again selects EDIT. Referring again to Figure 26, the indexer template 2612 can be edited 
only by adding an operator panel, a station or an axis specification, or by deleting a station or 
axis specification. Therefore, referring to Figure 33, in this case, the EDIT menu would 
provide five options: ADD STATION, ADD AXIS, ADD OPERATOR PANEL, DELETE 
STATION, and DELETE AXIS (delete options are only provided after station or axis has 
been added). At the indexer level an operator panel is optional and should only be provided 
when required to meet job specific characteristics. 

[00837] As with the machine module, here, where an axis is to be added to the indexer 

Tl, the user would select ADD AXIS and name the axis. The editor 2962a would then 
provide an axis module reference below the indexer module reference Tl and indented in the 
tree section 3149 and provide an axis icon in the floor plan section 3150. In the present 
example, the indexer Tl includes a "transfer" axis shown below the indexer "Tl" reference in 
section 3149 and shown as transfer icon 3158b in section 3150 of Figure 33. The transfer 
icon 3158b initially appears near the top of the floor plan section 3150 and is dragged down 
next to the indexer icon 3160 to signify the relationship therebetween. 
[00838] To add a station to the indexer, the user selects ADD STATION and names 

the specific station. The editor 2962a then provides a station module reference in the tree 
section 3149 and a station icon in the floor plan section 3150 which can be dragged into its 
proper location next to the indexer icon 3160. Additional stations are selected in the same 
manner but must be provided different names. 

[00839] In the present example, because there are five separate stations, the user adds 

five separate stations to the floor plan, each of which is individually represented in both the 
tree 3149 and floor plan 3150 sections. In Figure 33, all five stations, named S1-S5, are 
shown as five separate icons 3366, 3367, 3368, 3369 and 3370. The icons have been 
positioned to show machine component relationships. 

[00840] This process of selecting and naming menu items to construct both the 

template-based machine tree and the floor plan continues until the floor plan is completely 
designated, from the machine level down to the axis level. A complete floor plan for the 
process is shown in Figure 34 including icons representing the indexer, five stations, a work- 
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unit named "LH" at the first station corresponding to a loader, a work-unit named "LV" at the 
second station corresponding to a drill, an LV unit at the third station corresponding to a 
turret drill, an LV unit at the fourth station corresponding to a horizontal mill, an "RH" at the 
fifth station corresponding to an unloader, an operator panel represented by icon 3400, a 
master control panel represented by icon 3452, and a separate icon for each axis. 
[00841] In the tree section 3149, LH stands for "left horizontal" meaning the work-unit 

is positioned on the left hand side of its associated station and moves horizontally with 
respect to the station. Similarly, LV stands for "left vertical" meaning movement is along a 
vertical axis and RH stands for "right horizontal" meaning the work-unit is positioned on the 
right hand side of its associated station and moves horizontally with respect to the station. 
Despite the drill, turret drill, and horizontal mill all having the name LV, each is 
distinguishable because of their parent/child associations with different parent stations. 
Importantly, the parent/child associations are recognized by the compiler. 
[00842] As in Figure 16, the loader at station SI in Figure 34 includes a single axis 

named "shuttle" 3458c. Similarly, the drill at station S2 includes two axes named "spindle" 
3458d and "slide" 3458e, and the turret drill at station S3 includes axes named "spindle", 
"slide" and "turret" (icons not shown). The mill includes axes named "spindle" 3458f, "main 
slide" 3458g and "cross slide" 3458h, and the unloader includes an axis named "ejector" 
3458L 

[00843] When the floor plan is completed, the portion of the template-based machine 

tree in tree section 3149 is completely designated. Next, the special editors can be used to 
define the characteristics of each axis 3458a-3458i and the control panels, as well as define 
sequences of axis movement. 

[00844] Referring to Figure 34, the horizontal mill is represented in the floor plan 

image as the fourth station S4 and all other components connected thereto. Thus, station S4 
includes a left vertical mill LV having a local control panel represented by icon 3400 and 
spindle, main slide and cross slide axis represented by axis icons 3458f, 3458g, 3458h. 
[00845] 2. Axis Editor 

Referring again to Figure 34, when an axis icon is selected, the machine editor 2962a 
switches editing control to the axis editor 2962b which allows a programmer to specify axis 
characteristics. Referring again to Figure 29, the axis editor 2962b, like the machine editor 
2962a, follows the same process for gleaning new image information to create new modules 
and populate existing modules. The only difference is that the axis editor 2962b and machine 
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editor 2962a glean required information from different images and create and populate 
different module types. 

[00846] Figure 35 depicts a control diagram 3574 for the main slide linear axis, as 

displayed on a programming monitor, along with additional information required to derive 
data for a template compiler. A flow chart of the process by which the user creates the 
control diagram is depicted in Figure 36. Initially at process step 3572, the user constructs a 
behavior profile 3570 that is similar to the control metaphor for the desired machine cycle. 
The behavior profile 3570 is illustrated in the upper right portion of the display in Figure 35 
between lines 3575 and 3576 representing the extremes of the linear motion. The remainder 
of the display designates "physical attributes" of the axis, which attributes constitute the input 
and output signals required to operate the machine according to the behavior profile. 
[00847] At the outset of defining the operation of the main slide axis, a blank behavior 

profile is displayed with only the outer lines 3575 and 3576 that correspond to the extremes 
of the linear movement of the main slide subassembly. An EDIT choice appears at the top of 
the profile in a menu bar which, when selected, provides a menu of items that can be used to 
define the axis. In particular, the menu will include switches, actuators, and work requests. 
A box 3573 in which the user enters the length of the machine stroke, i.e. the distance 
between positions DO and Dl also appears. In the present example, the stroke distance is 
16.0 inches and can be entered in the box 3573 by selecting the box 3573 and entering an 
appropriate stroke via a keyboard. 

[00848] In Figure 36 the user uses the edit menu to select a menu item on the terminal 

screen to define one of the limit switches, for example a switch for the fully returned position 
of the subassembly. After that selection, a limit symbol is displayed on a monitor and box 
3577 appears to the left of the symbol within which the user enters the switch name, such as 
"returned LS". A schematic representation 3580 of the limit switch appears adjacent to its 
symbol to indicate whether the limit switch contacts close or open when struck, or tripped, by 
a subassembly dog. A dog symbol 3582 also appears on a horizontal line 3578 which 
represents the linear axis of movement. One end of the dog symbol 3582 initially abuts the 
LEFT vertical line 3575 and another vertical line 3584 appears at the other end of the dog 
symbol. 

[00849] The graphical representation of the limit switch indicates when the limit 

switch is sending an active input signal to a programmable controller with respect to the 
positions of travel by the main slide subassembly. At step 3585, the user indicates whether 
the switch is normally opened or closed. This is accomplished by using a mouse or the keys 
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on a keyboard to place the cursor over the schematic symbol 3580 and press the button to 
toggle the symbol open or closed. In a similar manner at step 3587, the user "grabs" the dog 
symbol 3582 to position the symbol along line 3578 to indicate positions on the axis where 
the dog trips the limit switch. The length of the dog symbol 3582 can be changed by using 
the cursor to grab one end of the symbol and stretch or contract the dog symbol. As the 
position and length of the dog symbol changes, so does the position of the vertical line 3584 
which indicates the location along the linear axis at which the dog engages and disengages 
the corresponding limit switch. The dog symbol 3588 for the advanced limit switch also is 
created on the control diagram in this manner by the user again selecting the limit switch 
menu item at step 3590. Defining the other limit switch (i.e. "advanced LS") also creates an 
additional vertical line 3586 on the control diagram 3566. 

[00850] The definition of the two limit switches divides the stroke length into three 

segments referred to as positions 3592, 3593, and 3594. The location and length of the dog 
symbols 3582, 3588 designate in which of these positions 3592-3594 the corresponding limit 
switch will be tripped by a carriage dog. In the present example, the returned limit switch is 
tripped by the dog when the subassembly is stopped in the "returned" position 3592. The 
advanced limit switch is tripped by the dog only when the subassembly is at the "advanced" 
position 3594. When neither the advanced nor returned LSs are tripped, the subassembly is 
in an "intermediate" position. As the limit switches are employed to signal when 
subassembly motion should be stopped, the operational positions 3592-3594 relate to 
different sections of the control metaphor. Specifically, "returned" position 3592 corresponds 
to the stopped position at distance DO and position 3593 corresponds to the subassembly 
moving between distances DO and Dl. Similarly, position 3594 corresponds to the fully 
advanced position when the subassembly is stopped at distance Dl . The terms "position" and 
"operational position," as used herein, refer to physical locations at which the machine has 
different operating characteristics, for example movement speed and direction. A position 
may be a single physical location or a region of physical locations, such as the region 
between distance DO and Dl. 

[00851] After defining the signals for the two limit switches, the user then specifies the 

number of actuators (motors) which are employed to drive the subassembly. A separate 
block 3596 is created each time the user selects an ADD ACTUATOR menu item from the 
program editor software at step 3590. This enables the user to specify the number of motors, 
in this case one for the main slide motor. Each block 3596 is subdivided into three boxes for 
actuator name, speed (IN/MIN) and direction. The blocks 3596 may be subdivided further 
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depending upon the types of actuators, i.e. ... single speed-single direction, single speed-two 
direction, two speed-single direction, or two speed-two direction motors. In the present 
example, the main slide motor is a single-speed, two-direction device and thus its block 3596 
has a single-speed box 3597 and two-direction boxes "work" 3599a and "home" 3599b. At 
step 3600, the user enters the speed of the slide motor in box 3597 but does not designate 
direction since both the advancing and retracting motions are provided by this actuator type. 
The editor software loops through steps 3600-3602 until information has been provided for 
each actuator selected. 

[00852] Each time an actuator block 3596 is added, removed or edited, the graphical 

editor has a column for every direction and/or speed coil for the motors and a line which 
corresponds to all of the possible combinations of motor speeds going toward and away from 
the workpiece. The exemplary main slide motor can advance the subassembly toward a 
workpiece at 100 inches per minute. Similarly, the motor can be used to retract the 
subassembly from a workpiece at 100 inches per minute. A black dot in various matrix 
locations indicates which of the motors are energized and their direction to produce the speed 
listed in the right column of the matrix 3604. 

[00853] When the matrix 3604 is formed, separate horizontal bars 3606 and 3608 are 

created across the behavior profile 3570 above and below the zero speed axis 3610. Each of 
the horizontal bars 3606 and 3608 is formed by individual segments within each of the 
operational positions 3592-3594. At step 3604, the user grabs the segments of the horizontal 
bars 3606 and 3608 in the behavior profile 3570 and positions the segments vertically to 
indicate the advancing and returning speed at which the subassembly is to move within each 
of the positions 3592-3594. For example, when an advance request is received, the 
subassembly is to move from the returned position 3592 through the intermediate position 
3593 at a speed of 100 inches per minute. Upon the subassembly reaching the advanced 
position 3594 at distance Dl, the speed goes to zero by stopping the motor. Thus, the portion 
of the behavior profile 3570 above the zero speed axis 3510 corresponds to moving the 
subassembly toward a workpiece. A similar representation in Figure 35 is given for the speed 
of the subassembly away from the workpiece by locating the segments of horizontal bar 
3608. 

[00854] Referring still to Figures 35 and 36, the user then provides the names of 

separate request signals that indicate when the subassembly is to advance toward the 
workpiece and when it is to return. These names are placed into boxes 3512 and 3514 as 
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request signals to be used by the linear axis editor as described below. In the example these 
request signals have been named simply "advance" and "return". 

[00855] Next, the user is afforded an opportunity at step 3607 to define composite 

position signals, which are signals energized when an axis is within a specified region 
defined using a subset of operational positions 3592-3594. A composite position definition 
label box CCP 3521 is added to section 3516 of diagram 3574 each time a user selects an 
ADD COMPOSITE POSITION menu item. For each composite position added a user must 
enter a name in the label box CCP' and must select one or more operational positions by 
clicking the mouse-controlled cursor in the vicinity of the intersection of an imaginary 
horizontal line, extending from the center of the label box CCP 1 , and one of the operating 
position regions 3592, 3593 or 3594, each selection recorded by the axis editor as a graphical 
arrow 3518, 3519. In the example, a composite position named "cutter clear" 3517 is defined 
to be energized whenever the main slide subassembly is in either the "returned" or 
"intermediate" position. 

[00856] As the user creates the control diagram 3574 of Figure 35, the axis editor 

2962b converts icons and images from the diagram 3574 into module specifications required 
to define an associated axis module. Referring again to Figure 25, to completely define both 
physical and operating characteristics of an axis the editor 2962b must glean information 
from the axis diagram 3574 to populate the module specification named "switch package" 
2591a and two module list specifications named "trajectory" 2591b and "actuator" 2591c. 
[00857] Referring to Figures 25, 32 and 35, to define the axis module 2508 so as to 

correspond to control diagram 3574, while a user is constructing the diagram 3574, the editor 
2962b identifies all limit switches, positions, composite positions, actuators, trajectories, and 
moves from the diagram 3574, one at a time, at block 3545. 

[00858] Each time a user designates a limit switch, request, actuator, position or 

composite position, the editor 2962b identifies the designation and populates an appropriate 
module or creates a new module. In the main slide control diagram of Figure 35, the editor 
2962b would identify both the returned limit switch 3538 f and advanced limit switch 3539', 
both the main slide advance 3512 and return 3514 requests, the main slide motor actuator 
3596, the main slide positions including "returned", "intermediate", and "advanced" 3592, 
3593 and 3594 respectively, the composite position "cutter clear" CCP 1 and various moves 
corresponding to both the return 3514 and advance 3512 trajectories. The advance trajectory 
3512 would include an "initial" move corresponding to position 3592, an "intermediate" 
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move corresponding to position 3593 and a "final" move, which slows the subassembly to 
zero speed, corresponding to position 3594. 

[00859] At block 2251, after each of the axis designations, the editor 2962b populates 

corresponding lists, placing limit switches in the limit switch module list specification 3794, 
positions in the position module list specification 3795, trajectories in the trajectory module 
list specification 2591b, actuators in the actuator module list specification 2591c, composite 
positions in the composite position module list specification 2591 d and moves in the 
associated move module lists 2596g in Figure 25. In addition, for each list entry, the editor 
2962b creates a new module at block 147. For example, referring to Figures 35 and 37, for 
the main slide control diagram 3574 the limit switch module list specification 3794 in Figure 
37 would include module references named "returned LS" 3538 and "advanced LS" 3539 
while the positions list 3795 would include module references named "returned" 3592, 
"intermediate" 3593 and "advanced" 3594. Referring to Figures 35 and 25, the trajectory 
module list 2591b would include module references named "advance" and "return" 
corresponding to requests 3512 and 3514 respectively and the actuator module list 
specification 2591c would include a single module reference named "motor" of the type 
actuator corresponding to designation 3596. Referring to Figure 39, the module list 
specification named "move" for the module of type trajectory named "advance" would 
include references to "initial," "intermediate" and "final" moves and the list named "move" 
for the module of type trajectory named "return" would also include references to "initial," 
"intermediate" and "final" moves. Each list entry would correspond to a different module. 
[00860] Referring to Figure 38 the position template 3803 includes four separate lists 

3804a, 3804b, 3804c and 3804d corresponding to the two possible types of limit switches 
and the two possible states of each type of switch (i.e. normally open (NO) tripped, NO 
released, normally closed (NC) tripped, and NC released.) Referring also to Figure 35, the 
editor 2962b correlates positions 3592, 3593 and 3594 with tripped and untripped switches 
and switch type (i.e. NO or NC) to populate each of the module list specifications 3804a- 
3804b of Figure 38 with switches in conditions that correspond to a position. 
[00861] For example, referring again to Figure 35, when the subassembly is in the 

returned position the "returned LS" 3538 is tripped and the "advanced LS" 3539 is released. 
Assuming both the returned 3538 and advanced 3539 switches are normally open (NO), the 
returned position 3592 would include one normally open and tripped returned LS 3538 and 
one normally open and released advanced LS 3539. Recognizing this, the editor 2962b 
would populate the NO tripped LS module list specification 3804a with the returned LS 3538 



-183- 



and would populate the NO released LS module list specification 3804b with the advanced 
LS 3539. The other two list specifications 3804c and 3804d in the position template 3803 
would be left empty. 

[00862] Referring to Figures 35 and 38, axis editor 2962b creates a composite position 

module based on template 3803a for each composite position in section 3516 of diagram 
3574. The editor provides each module a name 3801 corresponding to the name in label box 
CCP' and provides a "selected positions" module list specification 3804e corresponding to the 
names of the selected operational positions 3518 and 3519. The single rung in template 
3803a generates a simple logic circuit that energizes a signal whose name corresponds to 
module name 3801a whenever any one of the positions in the selected positions module list 
specification 3804e is energized. 

[00863] Referring to Figures 25 and 39 the editor 2962b creates a trajectory module 

based on trajectory template 3909 for every trajectory referenced in the trajectory module list 
specification 2591b. 

[00864] The second rung 3913 determines if the trajectory associated with the specific 

module is at its start position. This is done by using an OR list macro as explained above. 
The OR list macro and associated logic 3915 determines if any other trajectories are done. 
Where any other trajectory is done, it is assumed that the present trajectory is at its start 
position. The third rung 3914 simply checks if the trajectory associated with the module is 
completed and is used by other trajectory modules to determine if they are at their start 
positions. The start and done status of each trajectory is used by the bar chart editor 2962d as 
described in more detail below. 

[00865] Referring now to Figure 40, a move module based on move template 4016 is 

provided by the editor 2962b for each potential move designated in a trajectory module. 
Each move template 4016 includes a unique module list named "coil request". The editor 
provides a coil request module based on the coil request template shown in Figure 41 for each 
coil request referenced in a move module 4016. 

[00866] Referring to Figure 42 the editor 2962b creates an actuator module based on 

actuator template 4218 for each actuator module referenced in the axis template 108. Each 
actuator module 4218 includes a module list 4219 called coil wherever a list of uniquely 
named coils are provided for the actuator associated with the parent actuator template 4218. 
[00867] Because the axis editor gleans information from diagram 3574 while a user is 

constructing the diagram and simultaneously constructs the portion of the template-based 
machine tree corresponding to the axis being designated, by the time diagram 3574 is 
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completed, all of the information required to provide LL logic to specify the axis is complete. 
This process must be repeated for each axis on the floor plan 3150. 
[00868] 3. Control Panel and Bar Chart Editors 

Referring again to Figure 34, at this point the only icons on the floor plan image that 
have not been completely defined are the main control panel 3452 and horizontal mill control 
panel 3400. In addition, while all of the separate axes for each machine element have been 
designated at this point, none of the axis movements have been linked together. 
[00869] To specify a control panel, a user must designate mode selection, manual 

control, and indicator devices. In addition, for each manual control device and each indicator 
device, the user must designate both the cycle and the specific function in the cycle to which 
the device relates. To this end, with reference to Figure 29, although the control panel 2962c 
and bar chart 2962d editors are separate, they must be used together. Initially, the control 
panel editor 2962c is used to identify modes of operation, mode selector switches 
corresponding to the modes of operation, and various cycles that are controllable via the 
control panel. Then, the bar chart editor 2962d is used to define the different functions and 
their temporal relationships that make up each cycle that is controllable via the control panel. 
Finally, after the cycles are completely defined, the control panel editor 2962c is again used 
to identify manual control devices, including lights, buttons and switches, that correspond to 
desired functions in the defined cycles. 

[00870] To define the horizontal mill control panel, a user selects icon 3400 in Figure 

34. When icon 3400 is selected, editing control passes in Figure 29 from the machine editor 
2962a to the control panel editor 2962c. Referring yet again to Figure 32, the control panel 
2962c and bar chart 2962d editors, like editors 2962a and 2962b, follow process 3243 in 
Figure 32 to glean information from screen images to create new modules and populate 
existing modules during image construction. There is one exception to this general rule and 
that is that the bar chart editor must also perform a bucketing step using the attributes table 
5031 of Figure 50 after a cycle has been defined to populate function lists in the module list 
specification sections of associated function modules. This will be described below. 
[00871] Referring now to Figure 44, the initial display for a preferred control panel 

editor 2962c includes a menu bar 4422, a name field 4424, and three specification fields: 
MODE CONTROLS, CYCLES, and MANUAL CONTROLS referred to by numerals 4425- 
4427, respectively. The menu bar 4422 includes five options, a conventional FILE option 
and MODES, CYCLES, CONTROLS and LIGHTS options that can be used to add or delete 
modes of operation, cycles, specific controls, or lights respectively. 
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[00872] Because all control panels have at least local and remote modes of operation, 

the control panel editor 2962c initially designates a single three-pole selector switch 
represented in the MODE CONTROLS field 4425 by icon 4430 which can be used to choose 
either a remote mode (AUTO), local mode (MAN), or an off state (OFF). If desired, a user 
can use the MODES option in menu bar 4422 to pull down a mode menu for creating other 
modes (tool change or service modes). If a third mode is designated via the modes menu, the 
icon 4430 is automatically altered to show a four-pole selector switch in the MODE 
CONTROLS field 4425. 

[00873] Other than icon 4430, initially there are no other designations in fields 4425, 

4426 and 4427. Because manual controls have to be related to some cycle function, prior to 
designating manual controls, machine cycles have to be defined. To this end, a user can 
choose the CYCLES option from menu bar 4422 to pull down a cycles menu to designate 
required cycles. When a single cycle is added, the editor 2962c prompts the user to name the 
cycle. When a cycle is added, an icon including a user-assigned name is placed in the 
CYCLES field 4426. In the present example, the horizontal mill control panel includes only 
two cycles, a mill cycle including movements of the main slide and cross slide subassemblies, 
and a spindle cycle for turning on and off spindle. Therefore, two cycle icons 4432 and 4434 
corresponding to mill and spindle cycles are referenced in field 4426. 

[00874] To define each cycle, the user separately selects each of the cycle icons 4432, 

4434 to enter the bar chart editor 2962d two different times. Referring to Figure 45, a bar 
chart image 4536 that would be constructed for the mill cycle using the bar chart editor 
2962d is depicted. It should be readily apparent that the bar chart image 4536 constructed 
using the bar chart editor 2962d is very similar to a conventional chart. The similarity 
between a conventional bar chart and image 4536 is meant to make it easy for a user trained 
in the use of conventional diagrams to use the bar chart editor 2962d. 

[00875] When a user enters the bar chart editor 2962d, the initial image only includes 

basic required bar chart designations. Required designations include the cycle time box 
4538, first sequence 4540, second sequence 4541 and whole cycle 4542 icons, interlocking 
yield 4544 and stop 4545 symbols corresponding to icons 4540, 4541 and 4542 and 
REQUESTS 4546 LABELS 4547 and LATCH 4548 headings. 
[00876] The editor 2962d also provides a menu bar (not shown) including a 

REQUESTS option which allows a user to add or delete requests from the bar chart and a 
LABELS option allowing a user to label specific locations in the bar chart. To construct the 
bar chart image 4536, a user selects an ADD REQUESTS option from a pull down request 



-186- 



menu. Thereafter, the editor 2962d provides a complete listing of every possible request 
associated with the horizontal mill. For example, possible requests for the horizontal mill 
would include: cross slide advance, cross slide return, main slide advance, main slide return, 
spindle run, and spindle not run. In addition, other possible requests would include whole 
cycle, reset, first sequence, and second sequence requests to any other cycle, exclusive of the 
cycle depicted on the bar chart, defined subordinate to the horizontal mill in the machine tree 
(in this case, the spindle cycle 4434 identified in the cycle field 4426 of Figure 44). 
[00877] The bar chart editor 2962d gleans the axis request options directly from the 

axis images for the horizontal mill that were constructed using the axis editor 2962a. For 
example, referring again to Figure 35, main slide advance and return requests were 
designated in boxes 3512 and 3514. The cross slide advance and return requests would have 
been designated when the user constructed an axis image like the one in Figure 35 for the 
cross slide subassembly axis. The spindle requests would have been designated when the 
user constructed an axis image for the spindle axis. 

[00878] To specify a mill cycle, a user selects requests from the request menu for main 

slide advance, cross slide advance, main slide return and cross slide return. Each time a 
request is selected, the editor provides a request box 4550, 4551, 4552 or 4553 in Figure 45 
under the REQUESTS heading. In addition, referring also to Figure 46, the editor 2962d 
provides two blank sequence boxes to the right thereof under the CYCLE TIME designation 
4638, the sequence boxes divided by the LATCH designation indicating division between 
first and second sequences. Thus, there are two separate columns 4656, 4658 next to the 
request boxes 4650-4653, a first sequence column 4656 and a second sequence column 4658. 
[00879] With all of the requests selected, the user begins to order the sequence of 

requests by selecting the box in the first sequence column 4656 corresponding to the first 
request in the cycle. In the present example, the sequence of requests is main slide advance, 
cross slide advance, main slide return and cross slide return. Therefore, the user would first 
select the box in the first sequence column corresponding to the main slide advance request in 
box 4650. The editor 2962d would respond by placing a bar 4660 adjacent request box 4650 
in the first sequence column 4656. 

[00880] Next, the user would select the box in the second sequence column 

corresponding to the first request in the second sequence. In the present example, the first 
request in the second sequence is main slide return. The user would select the box in the 
second sequence column 4658 corresponding to the main slide return. The editor 2962d then 
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places a function bar 4662 in the selected box. At this point, the beginning requests in the 
first and second sequences have been identified. 

[00881] Next the user must select the second requests in the first and second 

sequences. In the present example, the second request in the first sequence is the cross slide 
advance request in request box 4651. To place a function bar for the cross slide advance 
request, the user selects box 4651 and drags a ghost image (not shown) of the box into first 
sequencing column 4656. To place the cross slide advance request after the main slide 
advance request, the user drags the ghost image until it is clearly in the second half of the first 
sequence column 4656. The user then releases the ghost image. To place the cross slide 
advance request in front of the main slide advance request, the user would release the ghost in 
the first half of the first sequence column 4656. The ghost image is depicted as a cross hair to 
aid the user in this process. 

[00882] Referring again to Figure 45, when the ghost image is released, the editor 

2962 d divides the first sequence column into first and second columns 4564, 4565 using a 
vertical "done" line 4569 and provides a bar 4567 corresponding to the cross slide advance 
request in box 4551. In addition, the editor 2962d shortens bar 4560 so that bar 4560 ends 
where bar 4567 begins, indicating that functions related to bars 4560 and 4567 do not 
overlap. In other words, the function related to bar 4560 is done at done line 4569. 
[00883] A function bar for the cross slide return request may be placed in the second 

sequence in a similar fashion, but closer inspection reveals that correct placement of the cross 
slice return function bar requires another technique. 

[00884] In this case, the cross slide return action is expected to start as soon as the 

main slide reaches the intermediate cutter clear position CCP, and is expected to continue in 
parallel with the remainder of the main slide return action until both actions are complete. 
So, referring again to Figures 45 and 46, before a function bar for the cross slide return 
request can be correctly placed, it is necessary to indicate on bar chart 4636 an intermediate 
"done" line bisecting the extent of the main slide return function bar 4662 that represents the 
achievement of the cutter clear position CCP. 

[00885] A bar chart editor 2962d, although capable of gleaning information from its 

functions about intermediate positions, is not capable of determining which of many such 
positions are needed on the display 4536, while displaying all such positions is clumsy and 
detracts from the overall usefulness of the display. In the preferred embodiment, a user is 
required to assist the editor 2962d by choosing, on a function by function basis, which 
intermediate positions in each function need to be indicated on the display 4536. This is done 
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through a function dialog that is activated by clicking between the end triangles of a function 
bar with the mouse-controlled cursor. 

[00886] Referring again to Figures 45, 46 and 35, a user first selects the bar 4562 

associated with the main slide return request. A function dialog gleans information about 
outputs 3516 and composite positions from a control diagram 3574 of the main slide axis 
captured by an axis editor 2962b. The function dialog presents this information to a user in a 
list of "positions" traversed by the main slide return trajectory - initial, intermediate, and 
final-in chronological order of traversal. A user may select one or more intermediate, 
positions for display. In this case, a user indicates that the composite position "cutter clear" 
CCP f is needed on the display. The bar chart editor 2962d then creates a vertical line 4570, 
bisecting the main slide return function bar 4662, and splitting the second sequence column 
4658 into columns 4572 and 4573. 

[00887] With reference to Figure 45, a user can select a box at the intersection of the 

row containing the cross slide return request box 4553 and the newly created column 4573. 
The bar chart editor 2962d then creates the cross slide return function bar 4574 in the selected 
box such that the leftmost end of bar 4574 meets the intermediate position line 4570 and the 
rightmost end of bar 4574 meets the vertical line 4576. 

[00888] Initially, all functions provided on a bar chart image 4536 using the editor 

2962d are assumed to be normal functions (i.e. can be performed in either forward or reverse 
directions and can be repetitively performed during manual operation in a single cycle). 
However, the preferred editor 2962d allows a user to specify non-reversible or non- 
repeatable functions. This is accomplished by again activating the function dialog by 
clicking between the end triangles of a function bar and making the appropriate selection in 
the function type section of the dialog. For example, by clicking bar 4567 and selecting 
"non-repeatable" in the function type section of the function dialog (not shown), the function 
associated with bar 4567 can be made non-repeatable. Similarly, a bar can be made non- 
reversible by activating the function dialog and selecting "non-reversible" in the function type 
section. A non-repeatable function is designated by a bar having the number "1" adjacent its 
leftmost triangle. In Figure 45, bar 4567 is so designated. Similarly, a ">" appearing 
adjacent to the leftmost triangle indicates a non-reversible function (see bar 4562). This 
information is gleaned by the editor 2962d for choosing function mapping in function 
modules (see Figure 49 A). 

[00889] Referring to Figure 45, as a user creates different functions on the bar chart 

image 4536, the editor 2962d creates additional stop and yield icons corresponding to various 
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image elements. In particular, at the beginning of each separate function 4560, 4567, 4562, 
4574 the editor 2962d provides both a stop 4545 and a yield 4544 icon above the bar chart 
grid. The stop 4545 and yield 4544 icons allow a user to condition functions on the 
completion of other functions, cycles or other system input sequences. For example, to limit 
the possibility of spindle damage, it may be desired to make performance of the cross slide 
advance request contingent upon the horizontal mill spindle being in an "on" state. Either of 
the stop 4545 or yield 4544 symbols can be used for this purpose. 

[00890] To define contingencies for the cross slide advance request in request box 

4551, a user may select yield icon 4544 which would provide a contingency screen 4574 
allowing a user to add or remove contingencies from a contingency list. Referring also to 
Figure 47, one embodiment of a contingency screen would include two separate fields, one 
field 4780 listing all possible machine contingencies. The other field, a CHOSEN 
CONTINGENCY field 4781, would list selected contingencies. In addition, the screen 4702 
would include a menu bar 4782 allowing a user to add and delete contingencies to and from 
the CHOSEN CONTINGENCY field 4781. To make the cross slide advance contingent 
upon a spindle on state, the user selects a spindle on contingence from field 4780. The editor 
then adds the "spindle on" contingency to field 4781. Once a complete contingency list has 
been formed, the user saves the list and performance of the cross slide advance of Figure 45 
is then conditioned upon all contingencies in the list associated with yield icon 4544 being 
completed. 

[00891] The stop symbols 4545 are similar to the yield symbols in that a list of 

contingencies can be formed which must be satisfied prior to continuing a sequence. 
However, whereas yield symbols 4544 apply only to functions beginning at the yield icon, a 
stop symbol 4545 applies to all functions beginning at or after the stop icon but before the 
end of an associated half-cycle sequence. For example, contingencies referenced in a 
contingency list associated with stop symbol 4545" must be met at line 4576 and at line 
4569. 

[00892] In addition to contingencies on functions, sometimes it is necessary to put 

contingencies on the performance of the first and second sequences of a cycle. This kind of 
contingency affects the performance of a sequence independently of the contingencies on the 
functions making up that sequence. In other words, these are contingencies on "cycling" a 
cycle. 

[00893] Contingencies specified using a stop sign 4545 are conditions needed in order 

to initiate and continue performance of the first sequence of the cycle. In contrast, 
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contingencies specified using a yield symbol 4544 are conditions needed only to initiate 
performance of the first sequence of the cycle, but are not required thereafter. 
[00894] For example, a user may select yield icon 4544 associated with first sequence 

request 4540 causing the bar chart editor to provide a contingency screen 4574 for the first 
sequence. By placing a "spindle on" condition in the CHOSEN CONTINGENCY field 4781, 
the user makes initiation of the first sequence conditional upon the spindle being in an "on" 
state. This contingency is in addition to a similar, but different, contingency placed on the 
cross slide advance request, which is a function performed as a part of the first sequence. 
[00895] Both the function and first sequence contingencies apply the same "spindle on" 

condition, but the meanings are different and, what's more, complementary. Sequence 
contingencies are used to avoid initiating, continuing, or resuming performance of a sequence 
of operations that have little or no hope of being completed successfully or safely. In this 
case, if the spindle state is not "on" when a first sequence request is made, there is little or no 
hope that the spindle will be "on" when the cross slide advance request requires it to be so. 
Specifically, the first sequence contingency avoids advancing the main slide when it is 
already known that the cross-slide cannot advance. This avoids unnecessary machine activity 
that wastes time, energy, and may require the attention of a machine operator to undo before 
that cycle can be restarted. Sequence contingencies specified using a stop symbol also 
prevent unintended "spontaneous" resumption of sequence performance and, therefore, any 
requested functions that may have stopped due to a related function contingency, should a 
required condition that was lost suddenly be rectified. 

[00896] Similarly, second sequence contingencies may be specified using stop and 

yield symbols associated with a second sequence request icon 4541, while sequence 
contingencies may be specified common to both sequences using stop and yield symbols 
associated with whole cycle request icon 4542. 

[00897] Referring again to Figure 51, preferably, after a complete cycle has been 

defined using the bar chart editor 2962d, the editor 2962(1 gleans information for each 
individual function from the bar chart image 4536 and assigns buckets, start positions, and 
safeties to each function according to Figure 50 attributes table 5031. Every start position is 
uniquely named and placed in a bucket M while every safety designated using icons 4544 or 
4545 is placed in a bucket O. 

[00898] Referring to Figure 52, to assign buckets for all functions, the editor 2962d 

starts with the first function in a bar chart, labels that function an original observing function 
at block 5252, and works backward to bucket all other cycle functions until it reaches the 
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inverse of the observing function. Referring also to Figure 45, to assign buckets for functions 
4560, 4567, 4562 and 4574, the editor 2962d would first label function 4560 the observing 
function. Then at block 4553, the editor 2962d would label the function prior to function 
4560, in this case function 4574, as the observed function. At block 4554, the editor 2962d 
assigns the observed function 4574 to a bucket of the observing function 4560 according to 
the attributes table 5031 illustrated in Figure 50. The bucketing process is explained below 
with reference to Figure 53. 

[00899] In Figure 52, at block 5255, the editor 2962d labels the function prior to the 

instantaneous observed function as the next observed function. In Figure 53, function 5362 
would be labeled the observed function. At decision block 5256 the editor 2962d determines 
if the observed function 5362 is the inverse of the observing function 5360. Where the 
observing function 5362 is not the inverse, the editor 2962d returns to block 5254 and 
buckets the observed function. The editor 2962d repetitively cycles through blocks 5254- 
5256 until the observed function is the inverse of the observing function. 
[00900] In a preferred embodiment, the observed function 5362 is the inverse of 

observing function 5360 and therefore, at decision block 5256, the editor 2962d branches to 
block 5257 and labels the function prior to the instantaneous observing function as the 
observing function. In the present case, function 4574 would be labeled the observing 
function. At decision block 5258, the editor 2962d determines if the observing function is 
the original observing function. If this condition is met, the editor 2962d stops the bucketing 
process. If the observing function is not the original observing function, the editor 2962d 
passes control back up to block 5253 and begins the process over again. Thus, the editor 
2962d assigns to buckets all of the needed required functions for every function in a cycle. 
[00901] Referring now to Figure 53, the bucketing process of block 5254 is illustrated 

as process 5360. To bucket an observed function, the editor 2962d first determines whether 
or not the observed function is stable relative to the observing function at decision block 
5362. 

[00902] Where the observed function is not stable, the editor 2962d determines if the 

observed function is canceled by the observing function or canceled by some other function 
at decision block 5370. Where the next function is canceled by some other function, the 
editor 2962d next determines whether or not the observed function is in the same half-cycle 
as the observing function at block 5378. Where the observed function is in the same half- 
cycle as the observing function, at decision block 5379 the editor 2962d determines whether 
or not the observed function incorporates a position or a latch. Where the observed function 
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incorporates a position, at block 5380 the editor 2962d buckets the observed function as type 
A. Referring also to Figure 49a, assigning a function to a bucket entails placing a unique 
name for the function in the appropriate list in the module list specification section 2342 of 
the function template 2336 associated with the observing function. In this case, where a 
function is placed in bucket A, the function is unstable, is canceled by the observing function, 
is in the same half-cycle as the observing function and incorporates a position and therefore 
would be placed in module list specification. Similarly, as other functions are assigned to 
buckets, they are placed in other lists in the module list specification section 2342. 
[00903] After blocks 5379 and 5380, at block 6000 the editor 2962d determines if the 

observed function incorporates a latch. Note that a function can incorporate both a latch and 
a position. Where the observed function is not stable, is canceled by a function other than the 
observing function, is in the same half-cycle as the observing function and incorporates a 
latch, at block 5381 the editor 2962d assigns the observed function to bucket C. 
[00904] Referring again to decision block 5378, where the observed function is not 

stable, is canceled by a function other than the observing function, and is not in the same 
half-cycle as the observing function, the editor 2962d passes control to decision block 5382 
to determine whether or not the observed function incorporates a position. Where the 
observed function incorporates a position, the editor 2962d assigns the observed function to 
bucket B at block 5383. At blocks 6002 and 5384, where the observed function incorporates 
a latch, the editor 2962d assigns the observed function to bucket D. 
[00905] Referring again to decision block 5370 where the observed function is not 

stable but is canceled by the observing function, the editor 2962d passes control to decision 
block 5371 and determines whether or not the function is in the same half-cycle as the 
observing function. Where the observed function is in the same half-cycle as the observing 
function, the editor 2962d determines whether or not the observed function incorporates a 
position or a latch at decision block 5372. Where the observed function incorporates a 
position, the editor 2962d assigns the observed function to bucket G at block 5374. Where 
the observed function incorporates a latch, the editor 2962d assigns the function to bucket E 
at blocks 6004 and 5375. 

[00906] Referring again to decision block 5371, where the observed function is not 

stable, is canceled by the observing function, and is in the half-cycle opposite the observing 
function, the editor 2962d passes control to decision block 5373 to determine whether or not 
the observed function is a position. Where the observed function incorporates a position, the 
editor 2962d assigns the function to the F bucket at block 5376 and where the observed 
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function incorporates a latch the editor 2962d assigns the function to bucket H at blocks 6006 
and 5377. 

[00907] Referring once again to decision block 5362, where the observed function is 

stable, the editor 2962d determines whether or not the observed function is in the same half- 
cycle as the observing function at decision block 5363. Where the observed function is in the 
same half-cycle as the observing function the editor 2962d determines whether or not the 
observed function incorporates a position at block 5364. Where the observed function 
incorporates a position, the editor 2962d assigns the function to bucket I at block 5366. 
Where the observed function incorporates a latch the editor 2962d assigns the function to 
bucket K at blocks 6008 and 5367. 

[00908] Referring again to decision block 5363, where the observed function is stable 

and is in the half cycle opposite the observing function the editor 2962d determines whether 
or not the observed function incorporates a position at block 5365. Where the observed 
function incorporates a position, the editor 2962d assigns the function to bucket J at block 
5369. Where the observed function incorporates a latch the editor 2962d assigns the function 
to bucket L at blocks 6010 and 5368. 

[00909] After all of the necessary functions in a cycle have been assigned to buckets 

and added to appropriate lists by the editor 2962d, the editor also gleans from the control 
diagram 4536 in Figure 45 which half-cycle the function is in. Referring to Figure 49B, this 
information is used to label contact 4950. In addition, this information is used at compile 
time with the XPO and XPC pseudoinstructions as explained above. 
[00910] After a user completes the bar chart for the mill cycle including request 

designation, proper bar sequencing and proper contingency designations, the user must then 
go back to the control panel editor 2962c and select the next cycle to be defined. Referring to 
Figure 44, in the present example the user selects the spindle icon 4434 and reenters the bar 
chart editor 2962d to define the spindle cycle. The spindle cycle would include two requests, 
a "spindle on" request and a "spindle off request. The spindle on request would constitute 
the first sequence and the spindle off request would constitute the second sequence. As with 
the mill cycle, the user would construct a complete bar chart like the one in Figure 45, 
including requests, bars and contingencies for the spindle cycle. During construction, the 
editor 2962d would continue to glean information required to populate modules and create 
new modules and to assign buckets as described above. 
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[0091 1] After complete bar charts have been constructed for each cycle identified in 

CYCLE field 4426, if desired, the user can then define manual control devices and tie those 
devices to specific requests in the bar charts. 

[00912] In accordance with the example, it will be assumed that a user requires four 

separate manual push buttons on the horizontal mill control panel, one button each for the 
main and cross slide advance requests and one button each for the main and cross slide return 
requests. While buttons could be included for the spindle on and spindle off requests, for the 
purposes of this explanation it will be assumed that they are not needed. To define a push 
button for the main slide advance request, the user selects the CONTROLS option from menu 
bar 4422 which would provide a complete list of all requests associated with the cycles 
identified in the CYCLE field 4426. In the horizontal mill example, the request list includes 
"main slide advance' 1 , "main slide return", "cross slide advance", "cross slide return", "spindle 
on", "spindle off 1 , and "whole cycle", "first sequence" and "second sequence" requests for 
both the mill and spindle cycles. To designate a main slide advance button the user selects 
the main slide advance request from the list. The editor 2962c then provides a button icon 
4486 labeled "main slide advance". 

[00913] In a similar fashion, the user selects the CONTROLS option three more times, 

each time selecting a different possible request, the three selected requests being "cross slide 
advance", "main slide return" and "cross slide return". Each time a different request is 
selected, the editor 2962c provides a new icon 4487, 4488, 4489 labeled accordingly. At this 
point all of the manual control buttons have been defined and associated with different 
requests. 

[00914] To define indicator lights, the user selects the LIGHTS option from bar 4422. 

The editor 2962c provides a list of possible limiting positions associated with the requests in 
the mill and spindle cycles. The user selects a limiting position and then the editor 2962c 
provides an associated light icon. In Figure 44, two light icons are illustrated, one 4492 for 
the main slide return and another 4494 for the cross slide return. 
[00915] As with the machine 2962a and axis 2962b editors, while a user is 

constructing a control panel image and corresponding bar chart images using the control 
panel 2962c and bar chart 2962d editors, the editors 2962c and 2962d are simultaneously 
gleaning information from the images to further develop the template-based machine tree 
according to the process shown in Figure 32. Thus, additional modules are created and 
existing modules are populated until all required images have been completed. 
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[00916] With all of the modes, manual control and indicator light devices defined and 

all of the cycles corresponding to the horizontal mill defined, the editors have all the 
information required to provide LL logic to control the horizontal mill. To provide 
information required for all of the machine components, the user would step through editing 
with the axis 2962b, control panel 2962c, and bar chart 2962d editors for all machine 
components. 

[00917] After all required physical and operational characteristics of machine 

components are completely defined using the editors described above, the user would instruct 
the programming terminal to compile the entire template tree. Compilation is relatively 
simple and is depicted in Figure 48. Initially, at block 4840, the compiler expands all child 
modules into specifications in parent modules. For example, referring again to Figures 23 
and 24, the master control panel module 2406 is placed in the machine module 2398 where 
the master control panel is referenced at 2300. Similarly, all axis modules (herein the module 
name "air") are expanded into the machine module 2398 in place of the module list 
specification named Axis 2302 and all indexer modules (herein the module named "IT 1 ) are 
expanded into the machine module 2398 in place of the module list specification named 
Indexer 2304. The compiler works its way through the entire template-based machine tree, 
including portions provided by the axis 2962b, control panel 2962c and bar chart 2962d 
editors until all child modules have been expanded into their referencing parent modules. 
[0091 8] In Figure 48, at block 4850 the compiler allocates programmable controller 

memory for the modules and assigns memory addresses to fully qualified names defined by 
data definition statements in the modules. Next, at process block 4841, the compiler resolves 
the symbolic expressions into fully-qualified names. For example, a symbolic expression for 
a push button of a master control panel may be "S.MasterStartPB". In the present example, 
this symbolic expression would expand into the fully qualified name 
"ABl.MasterControlPanel.MasterStartPB". Similarly, the left horizontal work-unit of the 
fourth station in the present example would have the fully qualified name "AB1 .Tl .S4.LH" 
wherein LH stands for "left horizontal", S4 for "the fourth station", Tl for "the transfer" and 
AB1 for "the machine" generally. 

[00919] After all the symbolic expressions have been expanded into fully qualified 

names, at block 4842 the extended instructions such as AND and OR lists are replaced with 
LL logic. Thus an AND list macro corresponding to a list including ten entries will be 
replaced by a ten contact series set of LL instructions, each contact corresponding to a 
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different list entry. Similarly, OR list macros would be replaced with a set of LL instructions 
expanded in parallel. 

[00920] Next, at block 4843 the compiler would compile pseudoinstructions XPC 5 

XPO and OTX, removing LL logic from some LL rungs and expanding logic in others 
depending on job specific requirements. After block 4843, all that remains is a control 
program consisting entirely of conventional LL logic that can be used by a programmable 
logic controller to control the industrial process of a machine. 

[00921] It should be appreciated by those of ordinary skill in the art that the description 

herein is given only by way of example and that various modifications and additions might be 
made, while still coming within the scope of the invention. In particular, while the present 
template-based language has been developed for use in LL programming, other template- 
based languages could be developed for use with other industrial controller programming 
languages such as state diagram programming. The important aspect of the present language 
is not that it relates to LL, but rather the realization that extensions to normal programming 
language logic itself in conjunction with extensions that are separate from the language logic 
can be used to provide truly reusable programming logic that can be tailored to job-specific 
requirements. In addition, while the exemplary template set detailed above was specifically 
designed for the metal removal industry, it is anticipated that other template sets that account 
for industry specific idiosyncrasies will be developed for other industries, and the present 
invention is meant to cover all other such template sets. 

[00922] Moreover, while the description above described how computer editors can act 

as interfaces to facilitate programming, it is contemplated that a user could construct a 
template-based machine tree and compile a program without the use of a computer editor. In 
other words, using a template set, a user could designate and populate modules by hand and 
then compile the modules as in Figure 48. 

[00923] Furthermore, while preferred editors are described herein, any type of 

computer editor could be used to aid a user in programming using the template language. 
The important aspect of any editor is that the editor allow the user to input information from 
which the editor can glean a subset of information required to designate and populate 
required modules. In addition, while the present invention is described in the context of four 
editors, the inventive template language could be used with more special editors provided for 
specific applications or in the alternative, one editor could be used separately to provide LL 
logic for a single portion of a machine tree. 
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[00924] Visualization of Schematics 

The Designer Studio also utilizes the ECDB to ascertain typed connections (electrical, 
pneumatic, network, ...) within a control assembly or interfacing from/to a Control Assembly. 
This visualization enables a user to clearly see disparities between the connections 
improving the integrity of the resultant system. 
[00925] Bill of Materials 

The system also supports detailed bill of material information visualization. 
Controlled Resources contain properties of the resource controlled by the control assembly 
that place requirements (i.e., add constraints) on the structure of the assembly that facilitate 
more precise renderings of the enterprise control system. 

[00926] For example, a clamp 1 controlled resource has a safety constraint which 

requires a failing clamp to always fail in the open position. 
[00927] Requests or Conditions 

A request for an operation (optionally with confirmation) or request for a status of the 
external world determines how to handle complicated actions (initialization, robot protocols, 
...). For example, to determine if a part is present, control logic must be defined to SensePart 
with a request status returned to unambiguously determine if a part has been sensed or not. 
[00928] The placement of the timing chart and the control request bar chart in 

proximal position facilitates an optimal user experience. Automatic ordering of control 
commands based on the prescribed order from a timing diagram is a unique and powerful 
feature in accordance with a preferred embodiment. 
[00929] EC Integration with External Data Models 

_ (Re)Use resources created within the mechanical modeling environment to determine 
the Mechanical Resources that need to be controlled. 

_ Transform the process description (i.e., sequence of activities that the resources 

perform) to a timing diagram. 

[00930] EC Control System Design 

_ Provides catalog of reusable control sub-system components: Control Assembly ™ 
Type (see below for what is in a control assembly) 

_ Allows user to create Control Assemblies ™ that correspond to frequently used 
control subsystem design patterns. 

_ Allows user to sequence the Requests of Control Assembly Instances (i.e., Request / 
Timing Diagram) 

_ Allows user to connect the Control Assembly Instances electrically, pneumatically, 
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and hydraulically (i.e., "control system-wide schematic") 

_ Allows user to configure exceptional behavior (e.g., manual emergency power 
recovery). 

_ Allows user to layout HMI 

[00931] EC Simulation 

_ Visualization the LL execution 

_ Visualization the current step(s) the machine is waiting on 

_ Visualization the "control process", i.e., animate the Timing Diagram 

_ Use generated code via SoftLogix to animate in 3-D the workcell machines that 

simulate the process and the subsequent creation of the product 

[00932] Note: in EC all these simulations run off the same data model. 

[00933] EC Control System Implementation 

_ Bill of materials (from RS Wire Schematics) 

_ Make control system bill of materials and control system process available to the 

Machine and Process designers (i.e., export to CNext) 

_ Code generation 

_ Diagnostics Generation 

_ HMI (Visualization) Generation 

[00934] EC Control System Maintenance 

_ Diagnostics 

_ Keeping control system design consistent with Product, Process, and Machine Design 
_ Password protect to provide restricted access to LL and the capability to record and 
changes that are made to the LL that must be reengineered into the design. 
[00935] In an enterprise control system in accordance with a preferred embodiment a 

user must first abstract enterprise activities that are utilized to assemble parts into their basic 
steps. No machine or control resources are necessary for this definition process. An example 
in accordance with a preferred embodiment will be utilized to illustrate this process. To weld 
a part of a car door assembly together, a part must be loaded, the second part of the door must 
be loaded (clamped), the first welding operation is performed and the second welding 
operation is performed. Finally, the welded door assembly is unloaded and transported to its 
next station. 

[00936] Conversion of CATIA Activities Data to/from Timing Diagrams 

[00937] Overview 

Rockwell Automation and Dassault Systems are collaborating on a set of tools to 
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design and implement production machinery. This collaboration involves storing both 
structural information and process information in Dassault's CNext product line. Dassault 
Systems uses a different model to store process information in CNext than is used in 
Rockwell Automation's Control Designer Studio. In order to exchange data between 
Dassault and Rockwell, a Data Interchange File Format has been negotiated. Each company 
is responsible for converting between its own data stores and the Data Interchange File 
Format. This document describes the conversion between the Data Interchange File Format 
and Rockwell's Virtual Control Model database. 
[00938] Data Interchange Format 

The Data Interchange File Format consists of a text file containing only ASCII text 
divided into lines. Each line is either blank, or it contains one of the keywords (Activities, 
ActivityResources, ActivityPredecessors, ActivityAttributes, StructuralComponents) or it 
contains a series of comma-separated data fields appropriate to the preceding keyword. The 
document defining the fields and their formats follows: 

StructuralComponents 

StructuralComponentlD,PartOf,WorkcelllD,Label,Class 

string, string,string,string, string 

12345,0,1, Esl,Support 

23456, 1 2345, 1 ,Clampset1 ,Clampset 

Activities 

ActivitylD,ParentActivitylD,ActivityLabel,ActivityType,ActivityDuration 
string, string, string,string, numeric 

ActivityResources 

ActivitylD,StructuralComponentlD 

string.string 

ActivityPredecessors 
ActivitylD,PredecessorActivitylD 
string, string 

ActivityAttributes 

ActivitylD,AttributeKey,AttributeValue 
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string, string, string 

(a blank line ends one table and begins another) 

(there may be as many sections as needed, and the same 

table may appear several times in a file) 

[00939] Importing into Virtual Control Model 

In the interests of modularity, the function of importing data from this text file into the 
Rockwell VCM has been split into 2 steps. In the first step, the text file is parsed and an 
intermediate text stream of SQL statements is created. In the second step, the stream of SQL 
statements is executed against the VCM database. 
[00940] Parsing the Input File 

The file parsing tool is a Perl script which implements a state machine with the 2 
states READ JT ABLE JNTAME and READDATA. It begins in state 

READ_TABLE_NAME, in which it reads lines of input (ignoring blank lines) until it finds 
one of the valid keywords. When it finds a keyword, it sets up the expected names and types 
of data to follow and switches to state READ_DATA. If what it finds is not a valid keyword, 
it exits after logging an error. 

[00941] In the READ DATA state the tool reads successive lines of data, checks for 

the expected number of fields, and emits one SQL statement for each line read. The SQL 
statements are all INSERT statements, each inserting one row of data into the 
correspondingly-named table in the VCM database. When the tool reads a blank line, it 
changes state to READ_TABLE_NAME. End of file terminates the tool. 
ODBC Tool 

The tool that executes SQL statements against a database is a Perl script 
employing the Win32::ODBC extension. It is invoked from the command line with an 
argument specifying the name of the ODBC data source to be opened. Then it 
reads its standard input for SQL statements, each of which is executed in turn, and 
the success or failure of each statement is checked. If any statement fails, the entire 
process terminates and an error message is logged. After all statements have been 
executed, the data source is closed and the process terminates. 

Conversion to Timing Diagrams 

After execution of the preceding processing, the data from the Interchange File 
resides in a set of intermediate tables in the VCM database. Further processing is 
required to convert them to the format used by Rockwell's tools to display Timing 
Diagrams to the user. All of this processing is carried out in a single tool, because it 



-201- 



is interrelated, with later steps depending on the results of earlier steps. The 
processing begins with establishment of an ODBC connection to the VCM data 
source. An SQL query is executed to Find all top level Activities (usually only one). 

Timing Diagram creation 
A Timing Diagram is created for the specified Activity, using the Create a 
Timing Diagram query. 

Edge creation 

Every Timing Diagram has at least one Edge, the left Edge. The Create an 
Edge query is executed to create the left Edge. 
Request creation 

The Find all Requests on this Timing Diagram query is executed to identify 
Activities that will map to Requests. Then the Create a CNextRequest query is 
used for each of the Requests. For each Request, running a Count subsidiary 
Activities query determines if this Request requires a subsidiary Timing Diagram. If 
it does, BarChart creation, Edge creation, and Request creation are called 
recursively. This will go on until there are no more subsidiary Activities detected. 
After a subsidiary Timing Diagram has been created, it is necessary to execute 
Update SubBarChartID in CNextRequest. 
Associating Requests with Edges 

After all the Activities on a Timing Diagram have been created, they must be 
organized by relating them to Edges. As many Edges will be created as are needed 
to organize all the Requests on the Timing Diagram. The processing begins with 
executing Find all Requests on left Edge of Timing Diagram. Then, for each 
Request found, Update LeftEdge of Requests with no Predecessors is executed. 
At this point Create an Edge can be executed to create the new right Edge. 
Following this a loop is executed, where each iteration begins with executing Find all 
Requests for next Edge and continues by executing Update LeftEdge of other 
Requests and Create an Edge if any Requests were found. The loop terminates 
when no more Requests can be found. 
SQL Queries 

All of the database processing is carried out by executing SQL statements 
under control of a script or program. This guarantees portability of the processing 
between different database servers. The queries are described in the following 
sections. The words beginning with $ are variables that are substituted into the 
queries before they are executed. Most of the queries are self-explanatory, but the 
more complex ones are accompanied by textual clarification. 
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AND DCCEIementsTimes.DCCActionsID = Requests. DCCActionsID 

[00942] The first step in designing a control system utilizing an enterprise system in 

accordance with a preferred embodiment is presented below. The example from an actual car 
manufacturing station for a rear quarter panel assembly is utilized to assist one of ordinary 
skill in the art to make and use a preferred embodiment without undue experimentation. 
[00943] A control engineer initiates the Rockwell Automation Enterprise Controls 

Designer Studio in accordance with a preferred embodiment to initiate the process. The 
engineer creates a new project by selecting the new project and gives it an appropriate name, 
like NEWPROJECT. This activity causes the system to load the machine resources that 
require control to be loaded from the existing CAD database. A process description is also 
loaded from the existing CAD database. 

[00944] Data conversion to/from the ECDB 

One of the key tasks in creating an Enterprise Control Database (ECDB) is the creation of a 
uniform set of data structures and a set of mapping procedures to take data from disparate 
sources and import it into the ECDB. Some of these data sources include structural 
information (CAD models, etc.) and process information. In accordance with a preferred 
embodiment moves data into the ECDB and creates a Data Interchange File Format (DIFF) 
file, and then use tools that can populate a set of database tables from information in the 
DIFF. 

[00945] The ECDB also supports the export of data in a variety of formats than can 

then be used to generate input to a variety of design analysis and synthesis tools, such as 
Rockwell Automation's Control Designer Studio or Dassault's CNext process modeling 
system. 

[00946] The Data Interchange File Format consists of a text file containing only ASCII 

text divided into lines. Each line is either blank, contains one of the keywords, or contains a 
series of comma-separated value (CSV) data fields appropriate to the preceding keyword. 
Because of the flexibility of CSV, the number of fields and their formats will grow over time 
to allow very rich structure. 

The currently supported table keywords are: (Activities, ActivityResources, 
ActivityPredecessors, ActivityAttributes, StructuralComponents). These tables 
are defined below, where the n th element of the "ColumnValues" list is the storage 
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format of the table column whose name is the n th element of the "ColumnNames" 
list. The table definitions follow: 

Table=StructuralComponents 

ColumnNames=StructuralComponentlD,PartOf,WorkcelllD, Label, Class 
ColumnValues=string,string f string, string, string 

Table=Activities 

ColumnNames=ActivitylD,ParentActivitylD,ActivityLabel,ActivityType,ActM 
ColumnValues=string, string, string, string, numeric 

Table= Activity Resources 

ColumnNames=ActivitylD,StructuralComponentlD 
ColumnValues=string,string 

Table=ActivityPredecessors 

Colu mn Names=Activityl D, PredecessorActivityl D 
ColumnValues=string, string 

Table=ActivityAttributes 

ColumnNames=ActivitylD,AttributeKey,AttributeValue 
ColumnValues=string,string,string 

This file format supports an arbitrary number of database tables. The format is 
to be interpreted as follows: 

_ A blank line ends one table and begins another 

_ The first non-blank line after a blank line denotes the table name 

_ Subsequent non-blank lines denote data in CSV format 

There may be as many sections as needed, and the same, table may appear 
several times in a file. An example DIFF is shown below, with keywords highlighted 
in bold: 

StructuralComponents 

1 2345,0,1, Esl,Support 
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23456,12345,1 ,Clampset1 ,Clampset 
Activities 

12345,4367,Load„45 

Activity Resources 

12345,23456 

ActivityPredecessors 

Clampsetl ,Clampset2 

Activity Attributes 

This file format is illustrative only. Extensions (via additional columns) can be 
added to particular database tables, and new tables added, to support such 
concepts as Interlocks (triggering events) and Safeties (enabling events). 

In the interests of modularity, the function of importing data from the DIFF into 
the ECDB has been split into two steps. In the first step, the DIFF file is parsed and 
an intermediate text stream of SQL statements is created. In the second step, the 
stream of SQL statements is executed against the ECDB database. 

Step 1: Parsing the DIFF and generating SQL 

The file parsing tool has been implemented as a Perl script which implements a 
state machine with the two states READ_TABLE_NAME and READ_DATA. 
Execution of the Perl script begins with the program in state READ_TABLE_NAME, 
in which it reads lines of input (ignoring blank lines) until it finds a keyword. If the 
keyword is not a member of the valid keywords, the program logs an error and exits. 
Otherwise, after finding a valid keyword, the script program initializes a number of 
variables that define the expected names and types of data to follow. The program 
then switches to state READ_DATA. 

In the READ_DATA state the tool reads successive lines of data, checks for the 
expected number of fields, and emits one SQL statement for each line that has been 
read from the DIFF. The SQL statements are all INSERT statements, each inserting 
one row of data into the correspondingly-named table in the ECDB. 

When the Perl script program reads a blank line, it changes its state back to 
READ TABLE NAME. 
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Reading an End of File (EOF) terminates execution. 

Step 2: Executing the stream of SQL statements against the ECDB 

The tool that executes SQL statements against a database is a Perl script 
employing the Win32::ODBC extension. It is invoked from the command line with an 
argument specifying the name of the ODBC data source to be opened. Then it 
reads its standard input for SQL statements, each of which is executed in turn, and 
the success or failure of each statement is checked. If any statement fails, the entire 
process terminates and an error message is logged. After all statements have been 
executed, the data source is closed and the process terminates. The standard input 
stream for this program is usually the standard output of the Perl program of Step 1 
above. 

[00947] For each SQL query attempted, the program checks the return status. If the 

return status is an error state, the program returns the error text and terminates. Otherwise, the 
program terminates when all SQL statements have been successfully executed against the 
ECDB. 

[00948] At this point, the data has been successfully placed in the Enterprise Database 

in a canonical format, and can now be accessed by a variety of tools. In general, data 
translation is required from the ECDB internal format to a format that is acceptable to a 
specific tool. For example, Rockwell's Designer Studio program uses a format called Timing 
Diagrams to denote the activities performed by resources and bar charts to denote the 
requests made to the resources. 

Conversion from ECDB to Timing Diagrams 

The processing required for exporting data from the ECDB in a format 
compatible with Rockwell's tools to display Timing Diagrams to the user is described. 
All of this processing is carried out utilizing a single tool that processes the results of 
earlier steps. The processing begins with establishment of an ODBC connection to 
the ECDB data source. A SQL query is executed to Find all top level Activities 
(usually there is only one). 

Timing Diagram creation 

A Timing Diagram is created for the specified Activity, using the Create a 
Timing Diagram query. Code in Perl is shown below for converting information from 
CATIA process description to a timing diagram for use by the ECDB. 
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# prepare connection to Machine Resource DB 
$db = new Win32: :ODBC("VCM") || die $!; 

# prepare connection to Machine Resource DB 
$db = new Win32::ODBC("VCM") || die $!; 
=head2 mainline 

#for each parentless Activity CreateBarChart recursively 
=cut 

my $query = "SELECT * FROM Activities WHERE Activities.ParentActivitylD = XT; 

my(@rows) = (); 

if (! $db->Sql($query)) 

{ 

# read the entire set of rows 
while ($db->FetchRow()) 
{ 

# store result as a list of hashes 
push ©rows, {$db->DataHash()} ; 

} 

} 

else 
{ 

ReportSQLError($query); 

} 

# iterate through the array of rows, with no further DB access 
my $row; 

for each $row (@rows) 
{ 

&CreateBarChart($row->{"ActivityLabel"} , $row->{"ActivitylD"} ); 

} 

$db->Close(); 

# end of mainline 

#for each parentless Activity CreateBarChart recursively 
=cut 

my $query = "SELECT * FROM Activities WHERE Activities.ParentActivitylD = '0' "; 
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my(@rows) = (); 

if (! $db->Sql($query)) 

{ 

# read the entire set of rows 
while ($db->FetchRow()) 

{ 

# store result as a list of hashes 
push (grows, {$db->DataHash()} ; 

} 

} 

else 
{ 

ReportSQLError($query); 

} 

# iterate through the array of rows, with no further DB access 
my $row; t 
foreach $row (@rows) 

{ 

&CreateBarChart($row->{ ,, ActivityLabel"} , $row->{" Activity ID"} ); 

} 

$db->Close(); 

# end of mainline 

Edge creation 

Every Timing Diagram has at least one Edge, the left Edge. The Create an 
Edge query is executed to create the left Edge. A summary of the steps in the 
actual execution code follows: 

3. CreateBarChart 

4. CreateEdge 

5. for each Activity with this parent 

6. CreateCNextRequest 

7. find Activities with this parent with no ActivityPredecessors 

8. AssignLeftEdge 
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9. CreateEdge 

10. while any unassigned Activities with this parent remain 

11. for each ActivityPredecessor pointing to any Activity on previous edge 

12. AssignEdge 

13. CreateEdge 

14. return BarChartID 



Request creation 

The Find all Requests on this Timing Diagram query is executed to identify 
Activities that will map to Requests. Then the Create a CNextRequest query is 
used for each of the Requests. For each Request, running a Count subsidiary 
Activities query determines if this Request requires a subsidiary Timing Diagram. If 
it does, BarChart creation, Edge creation, and Request creation are called 
recursively. This will go on until there are no more subsidiary Activities detected. 
After a subsidiary Timing Diagram has been created, it is necessary to execute 
Update SubBarChartID in CNextRequest. 



Associating Requests with Edges 

After all the Requests on a Timing Diagram have been created, they must be 
organized by relating them to Edges. As many Edges will be created as are needed 
to organize all the Requests on the Timing Diagram. The processing begins with 
executing Find all Requests on left Edge of Timing Diagram. Then, for each 
Request found, Update LeftEdge of Requests with no Predecessors is executed. 
At this point Create an Edge can be executed to create the new right Edge. 
Following this a loop is executed, where each iteration begins with executing Find all 
Requests for next Edge and continues by executing Update LeftEdge of other 
Requests and Create an Edge if any Requests were found. The loop terminates 
when no more Requests can be found. 



Export of Timing Diagrams 
SQL Queries 

All of the database processing is carried out by executing SQL statements 
under control of a script or program. This guarantees portability of the processing 
between different database servers. The queries are described in the following 
sections. The words beginning with $ are variables that are substituted into the 
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queries before they are executed. Most of the queries are self-explanatory, but the 
more complex ones are accompanied by textual clarification. 

Find all top level Activities 
SELECT * FROM Activities WHERE ParentActivitylD = '0' 

Create a Timing Diagram 
INSERT INTO BarCharts 

(BarChartID, BarChartStrng, BarChartDescr, ModelD) 
VALUES ($BarChartlD, , $barChartStrng , I "From CATIA, 1) 
Create an Edge 
INSERT INTO Edges (EdgelD, EdgeNum, BarChartID) 
VALUES ($EdgelD, $edgeCount, $BarChartlD) 
Find all Requests on this Timing Diagram 
SELECT * FROM Activities WHERE ParentActivitylD = '$ParentActivitylD' 

Activities give rise to both BarCharts and CNextRequests, depending on their 
position in the hierarchy. A top level (parentless) Activity is always a BarChart, and a 
lower level Activity is always a Request, but if the lower level Activity has children, it 
will give rise to a subsidiary BarChart as well as a Request. 

Create a CNextRequest 

INSERT INTO CNextRequests 

(RequestID, LeftEdge, BarChartID, RequestOrder, Activity, Resources, 
SubBarChartID) 

VALUES ($RequestlD, 0, $BarChartlD, 0, 'SactivitylD', NULL, 0) 

Count subsidiary Activities 
SELECT COUNTf) AS ChildCount FROM Activities 

WHERE ParentActivitylD = 'SactivitylD' 

Update SubBarChartID in CNextRequest 
UPDATE CnextRequests 

SET SubBarChartID = $newBarChartlD 

WHERE RequestID = $RequestlD 

Find all Requests on left Edge of Timing Diagram 

SELECT * FROM Activities 

WHERE Activities. ParentActivitylD = 'SParentActivitylD' 
AND NOT EXISTS (SELECT * FROM ActivityPredecessors 
WHERE Activities. Activity ID = ActivityPredecessors.ActivitylD) 
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This query may be paraphrased as "select those Activities belonging to this BarChart 
and lacking a predecessor Activity". 

Update LeftEdge of Requests with no Predecessors 

UPDATE CnextRequests 

SET LeftEdge = $edgelD 

WHERE CNextRequests.Activity = '$ActivitylD' 
Find all Requests for next Edge 
SELECT R2.RequestlD 

FROM CNextRequests AS R1 , CNextRequests AS R2, ActivityPredecessors AS 

AP1 

WHERE R1. LeftEdge = $oldEdge 

AND APLPredecessorActivitylD = R1 .Activity 
AND R2.Activity = AP1 .ActivitylD 

This query may be paraphrased as "select those Requests whose predecessor 
Activity mapped to a Request linked to the preceding Edge." 

Update LeftEdge of other Requests 

UPDATE CnextRequests 

SET LeftEdge = $edgelD 

WHERE CNextRequests. RequestID = $RequestlD 
Select BarChart for export 
SELECT * FROM [BarCharts] WHERE BarChartID = $BarChartlD 

Create Ordered Edge List 
SELECT * FROM Edges 

WHERE BarChartID = $BarChartlD 
ORDER BY Edges.EdgeNum 
Select Requests for export 

SELECT * FROM Requests 

WHERE Requests. LeftEdge = $EdgelD 
ORDER BY Requests.RequestOrder 
Lookup Request Attributes 
SELECT ControlAssemblylnstances. Label AS InstanceLabel, 
DCCActions. Label AS ActionLabel, 
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DCCEIementsTimes.Time 
FROM Requests, 

ControlAssemblylnstances AS Cai, 

DCCActions, 

DCCEIementsTimes 
WHERE Requests.RequestID = $RequestlD 
AND Requests. ControlAssemblylnstancelD = Cai.ControlAssemblylnstancelD 

AND DCCActions.DCCActionsID = Requests. DCCActionsID 

AND DCCEIementsTimes. DCCActionsID = Requests. DCCActionsID 

[00949] Enterprise Controls 

Enterprise Controls (EC) is a single unifying construct for integrating control system design, 
simulation, implementation, and maintenance processes (via an integrated object model), and 
integrating control system design and deployment with external product, process, and 
machine data models (via an integrated enterprise-wide customer data model). The Designer 
Studio software provides enterprise control in accordance with a preferred embodiment. 
[00950] This EC Designer Studio incorporates software from various new software 

including Enterprise Controls Designer Studio, a transfer machine model, status based 
diagnostics and code generation engine, a PanelBuilder software comprising: a layout editor 
and a layout compiler, RSWire (schematics), RSLadder (display and monitor LL), RS 
SoftLogix 5 (simulator), RS Linx (communications gateway / router), PERL Scripting and a 
relational database such as Microsoft Access. 

[0095 1 ] The EC Designer Studio utilizes Java 1.1, Visual J++ 6.0 and Microsoft 

Application Foundation Classes (version 2.5). Figure 54 is a splash screen in accordance 
with a preferred embodiment. Figure 55 is the initial display for the Designer Studio in 
accordance with a preferred embodiment. 

[00952] The Designer Studio integrates with External Data Models such as 

Mechanical Resources panel which utilizes resources created within the mechanical 
modeling environment to provide the resources that need to be controlled. The data models 
can be based on "BIG" CAD (Unigraphics, SDRC, or CATIA) or "little" CAD (e.g., 
AutoCAD)] to determine the Resources (Mechanical, Robotic, and Operator). An important 
part in accordance with a preferred embodiment is a mechanism that determines which 
elements are to be controlled. 
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[00953] The Designer Studio also integrates a Mechanical Timing Diagram panel 

which can take on different dimensions based on the particular model which is employed. 
For example, when CATIA is utilized, the sequence of activities that the resources perform in 
their process representation of choice are transformed into a Mechanical Timing Diagram in 
accordance with a preferred embodiment. If AutoCad is utilized, then the Designer Studio 
must create a Mechanical Timing Diagram. 

[00954] This process is well suited for processes that use mechanical timing diagrams 

to describe their sequence of operations. One of ordinary skill in the art will readily 
comprehend that real control system design is done in small "chunks" that can be 
"rationalized" one at a time. In accordance with a preferred embodiment, these chunks will 
be referred to as Control Assemblies. 

[00955] Figure 56 illustrates a menu that is utilized to open a project in accordance 

with a preferred embodiment. Figure 57 illustrates a display menu that is utilized to select an 
existing project to load in accordance with a preferred embodiment. Figure 58 
[00956] Illustrates an Open Project dialog in accordance with a preferred embodiment. 

A user interacts with this display to open a database and read a Mechanical Resources 5810 
from the CAD database and transform the process description into a Mechanical Timing 
Diagram 5820. 

[00957] One panel 5810 contains a hierarchical tree of the Resources for the IAM98 

Workcell read from the CATIA CAD system and filtered to highlight control information. A 
second panel 5820 contains a Mechanical Timing Diagram that performs the sequencing of 
the activities (or operations) that the resources perform. A third panel (Control Resources) 
5800 contains the Control Assembly Types that are selected by the EC Designer Studio to be 
necessary for controlling the Mechanical Resources in the final panel Control Bar Chart 5830 
that is populated automatically by the system as control assemblies are created. 
[00958] EC Control System Design 

Control Engineers work on "small", manageable "chunks" of the control system. 
These chunks or control subsystems are referred to as Control Assemblies as shown in panel 
5800. Control Assemblies are created as a first step in defining the enterprise control in 
accordance with a preferred embodiment. A control engineer creates Control Assemblies 
(i.e., small chunks of the control system) to control the mechanical resources "that require 
control" (i.e., resources that have activities in the Mechanical Timing Diagram). 
[00959] For example a user can create a Control Assembly of type 

SafeBulkHeadClampSet 5840 in order to control clamps 2506A, 4502A, 5508B, 5509A, 
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5516A, and 5516B. Note that SafeBulkHeadClampSet was one of the Control Assembly 
Types predicted by the EC Designer Studio to be useful to the user to control some of the 
resources in the Mechanical Timing Diagram as evidenced by its name appearing in the 
Control Resources window 5800. 

[00960] These clamps perform the activities fixture (close) and release (open) in 

parallel on the Mechanical Timing Diagram. Figure 59 illustrates a menu display for 
facilitating an "Add Control Assembly" dialog 5900 in accordance with a preferred 
embodiment. Figure 60 illustrates the first menu in an "Add Control Assembly" dialog in 
accordance with a preferred embodiment. The Add Control Assembly dialog provides a 
catalog of reusable control sub-system components: Control Assembly Types (see below for 
the specification of a Control Assembly. In accordance with the example, the Control 
Assembly Type selected is a safe-bulkheadclampset 6000. 

[00961] After selecting the Type the user will click the New button. This user event 

initiates the Control Assembly Wizard shown in Figure 61 at 6100. 

[00962] The Control Assembly Wizard allows a user to create a Control Assembly 

corresponding to frequently used control subsystem design patterns and allows the user to 
actuate properties of that Control Assembly. Figures 61 to 67 illustrate a user experience 
with a wizard in accordance with a preferred embodiment. 

[00963] Figure 62 illustrates a wizard display in which a control assembly has been 

selected in accordance with a preferred embodiment. The user must specify a name for the 
new Control Assembly of Type safe-bulkheadclampset as reflected at 6200. 
[00964] In Figure 63, the user specifies the name of the new control assembly in 

accordance with a preferred embodiment. In the example, the name of the new Control 
Assembly is lstclamps.The Control Assembly Type is a reusable component containing a 
number of user selectable properties (or parameters), lstclamps is a specific instance of the 
component for which the user will set the properties. The Control Assembly Wizard defaults 
are set to automatically create a schematic (i.e., wiring diagram or WD) for the assembly and 
all the available diagnostics (defined by the Type) for the assembly are preselected. Finally, 
the documentation format is defaulted to HTML format. 

[00965] An important feature of the system is the built in diagnostics and 

documentation that are architected into each component. This feature allows a control 
engineer to receive a predefined set of diagnostics that are carefully tailored to the 
characteristics of each component and build diagnostics right into the control system 
automatically. Moreover, as the system is simulated and ultimately brought into production, 
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the diagnostics are available for integration and analysis from the beginning of the process 
through the life of the system. Thus, when a failure occurs in the system, there are built-in 
controls that facilitate immediate identification of the failure and remedy.Figure 64 illustrates 
a resource selection display in accordance with a preferred embodiment. A user is presented 
with a list of available resources 6400 from the Mechanical Timing Diagram that match the 
type of resource that the control assembly type 6410 can control and are not previously bound 
to other control assemblies. 

[00966] Figure 65 illustrates a selected set of controlled resources in accordance with a 

preferred embodiment. The selected resources are shown in box 6510 as they are selected 
from available resources shown at 6500. The user adds resources from the available list 6500 
to the controlled resources list 6510 of the resources that will be controlled by the control 
assembly lstclamps of type safe-bulkheadclampset 6520. Figure 66 informs the user of the 
control components that will make up the control assembly based on the resources chosen to 
be controlled in accordance with a preferred embodiment. The control components 6600 and 
their labels 6610 are provided to assist the user in designing a control strategy. Figure 67 
illustrates the final step in defining control assemblies in accordance with a preferred 
embodiment. The display window 6700 presents a specification of the control assembly that 
will be created if a user selects the Finish button. 

[00967] Figure 68 illustrates the processing that occurs when a user presses the finish 

button in accordance with a preferred embodiment. First, the Control Assembly IstClamps is 
added to the Control Resources hierarchical tree panel in the ECDB. The parent of 
IstClamps is the Control Assembly Type Safe-BulkHeadClampSet. The children of 
IstClamps 6810 are the requests or conditionals that determine the behavior of IstClamps. In 
this case IstClamps has two requests: extend and retract 6810. 

[00968] The requests (extend and retract) 6810 corresponding to the activities (fixture 

and release) of the clamps controlled by IstClamps are automatically added to the Control 
Bar Chart panel 6840. The bars 6830 denote the time period during which the extend and 
retract requests occur. The Control Bar Chart panel 6840 shows the sequence of requests 
made by the Control Assembly IstClamps. The Control Bar Chart 6840 is a control system- 
wide tool that shows the sequence of Control Assembly requests. 

[00969] There are relationships between the control assembly IstClamps 6810, the 

Mechanical Resources it controls, the Activities these resources perform, and the requests 
made by IstClamps to these resources to initiate their activities. 
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[00970] Figure 69 illustrates the selection processing associated with a particular 

control assembly in accordance with a preferred embodiment. To see these relationships a 
user selects IstClamps 6910 in the Control Resources panel. This action highlights 6940 the 
clamps that IstClamps controls in the Mechanical Resources panel, the activities 6930 that 
these resources perform in the Mechanical Timing Diagram panel, and the requests made 
by IstClamps to these resources to actuate their activities in the Control Bar Chart panel 
6920. 

[00971] Using the scroll bars we can arrange the Mechanical Timing Diagram and the 

Control Bar Chart to see the sequencing relationship between the Timing Diagram of the 
Mechanical Resource activities and the requests of the IstClamps control assembly. The 
activities of the clamps controlled by IstClamps and the requests of IstClamps occur in the 
same columns (i.e., during the same time period of the cycle). 

[00972] Figure 70 illustrates the processing of a control assembly in accordance with a 

preferred embodiment. When a user clicks the mouse on the retract 7000 request of 
IstClamps the user can see the activities 7010 controlled by the request. Figures 71 to 79 
provide additional displays in accordance with a preferred embodiment. 
[00973] Schematic Tool: Allows user to add the control system-wide schematic 

components such as factory services, rack layouts, ... and to connect the Control Assembly 
Instances electrically, pneumatically, and hydraulically via a control system-wide tool 
[00974] e.g., RSWire adapted to work off an integrated data model that allows a local 

(i.e., Control Assembly) schematic environment and a control system-wide tool that connects 
Control Assemblies and adds the additional schematics necessary to complete the Control 
System-wide design (e.g., Factory Services, Rack Layouts, ...) HMI Tool: Allows the user to 
combine the viewable entities in the control assemblies to layouts to monitor and control the 
process 

[00975] EC Simulation 

Visualization of the PLC LL execution is enabled by using RSLogix. Visualization 
of a current step(s) the machine is waiting on Visualization the "control process", i.e., animate 
the Bar Chart. Use generated code via SoftLogix to animate in 3-D visualization of the 
workcell machines in order to simulate the process and the subsequent creation of the product 
Note: in EC all these simulations run off the same data model. 

EC Control System Implementation 

Bill of materials (from RS Wire Schematics) 
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Make control system bill of materials and control system process available to the 

Machine and Process designers (i.e., export to CNext) 

Code generation Tool 

Diagnostics Generation Tool 

HMI (Visualization) Generation Tool 

EC Control System Maintenance 

Diagnostics 

Keeping control system design consistent with Product, Process, and Machine 
Design 

[00976] Password protect to provide restricted access to RLL and the capability to 

record and changes that are made to the RLL that must be reengineered into the design. 
[00977] A Control Assembly Component is a deployable control subsystem that 

exposes an interface (to Control System-wide tools) that is a composition of the following 
parts using a common object (or data) model and is easily configurable by setting properties. 

1 Control Components 

1 Definition: a control component is an entity that either sends a control 
signal, receives a control signal, or both sends and receives control signals. 

These components control the flow of the motive forces 

(electrical, pneumatic, and hydraulic) that cause mechanical operations to 
occur. 

2 Examples: solenoid valve (receives), proximity sensor (sends), Robot 

interface (both), PanelView interface (both), pushbutton (sends), indicator light 
(receives), motor controller (both), ... 
2 Mechanical Components 

3 Definition: a mechanical component that is required to 

implement or deploy the control subsystem (e.g., pneumatic hoses, check 
valves, ...) 
3 Logic 

4 Definition: the logic specifies the control and fault states, the 

transitions between states that the control components can attain (i.e., the 
restricted state space of the control assembly), the controller outputs which 
produce the transitions, and inputs to the controller determine the current 
state. 

The following examples identify three types of logic groupings: input 

only, output only, and input/output. 
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5 Examples: 

1 n-sensor PartPresent (input) 

1 States 

1 Part Absent 

2 Part Present 

3 Part out of position 

2 Transitions 

1 Part Absent => Part Present 

2 Part Present => Part out of position 

3 Part out of position => Part Absent 

4 Part Absent => Part Present 

5 Part Absent => Part out of position 

6 Part out of position => Part Present 

3 Outputs 

1 None 

4 Inputs 

1 all n off (Part Absent) 

2 all n on (Part Present) 

3 k of n on (k<n, k>0) (Part out of position) 

2 ClearToEnterLight (output) (e.g., single light also could be 

multiple lights) 
1 States 

1 LightOn 

2 LightOff 

2 Transitions 

1 LightOn => LightOff 

2 LightOff => LightOn 

3 Outputs 

1 LightOnSignal (LightOff => LightOn) 

2 Not LightOnSignal (LightOn => LightOff) 

3 SafeBulkHeadClamp (both) 

1 States 

1 Retracted 

2 Extended 

3 Between 

2 Transitions 
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1 Retracted => Between 

2 Between => Extended 
_3 Extended => Between 
4 Between => Retracted 



_3 Outputs 

1 Extend (both valves opened = 4 outputs high) 

2 Retract (main valve closed = 2 outputs high) 



cylinders) 



cylinders) 



both off) 



_4 Inputs 

1 Retracted (retract proximity sensors on for all 



Extended (extend proximity sensors off for all 
Between ( one or more sets of proximity sensors 



4 Fault 1 (one set of proximity sensors both on) 

5 Fault 2 (one or more of the set of sensors 

disagrees with the others for a nominally significant time period). 
A Diagnostics 

6 Definition: Status-based diagnostics - specifies the step(s) 



that the machine is currently waiting to occur (if a fault occurs it specifies the 
step(s) that were waiting to occur at the time of the fault, i.e., the symptoms). 
Note: this information is available for both well behavior and fault 



behavior. 

7 Definition2: Causal model-based diagnostics - use a model of 

causal relationships to develop rules that relate machine status to root 
causes. 

8 Examples: 

1 Consider that a human mechanic has incorrectly moved 

the mount location of a part present proximity sensor causing a 
misalignment. 

1 Status-based: determines that the machine is "waiting for 

part present sensor #2" (no automatic inference possible) 
2 Consider that the proximity sensor on a clamp cylinder 



has failed 

1 Status-based: determines that machine is "waiting for 

clamp cylinder 2504A" 
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2 Causal model-based: logic infers that the extend 

proximity sensor on cylinder 2504A has failed, or that cylinder 2504A is 
stuck. 

5 Schematics 

9 Definition: a schematic is a representation of the electrical, 

pneumatic, and hydraulic interface to the control assembly. 

1 0 Examples: 

1 (electrical 

2 (pneumatic 

3 Ihydraulic 

4 

6 Visualization 

1 1 Definition: entities within the control assembly that are 

useful to portray textually or graphically. 
1 2 Examples: 

1 Control Components (textually or graphically) 

2 Logic (graphically: RLL, Function Blocks, Axis-like 

diagrams, state diagrams ...) what ever conveys the logic to the user. 
3 Diagnostics 

1 Status messages 

2 Causal messages 

4 Schematics 

1 Typed connections (electrical, pneumatic, network, ...) 

within Control Assembly and to and from the Control Assembly (i.e., 
the interface to the Control Assembly. 

2 Bill of Materials (to deploy the control assembly) 

3 ... 

5 Controlled Resources 

6 Requests 

7 Controlled Resources 

13 Definition: properties of the resource controlled by the 

control assembly that place requirements (i.e., add constraints) on the 
structure of the assembly 

14 Example 

1 Clamp 1 

1 Safety constraint: if lose power clamp must fail open 
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JJ Requests or Conditions 

1 5 Definition: request an operation (optionally with 



confirmation) or request a status of the external world (color code) 

1 Request Action Request Status 

2 Request Action 

3 Request Status 

4 Note: how to handle complicated actions (initialization, 

robot protocols, ...) 

16 Examples: 

1 PartPresent 

1 SensePart (Request Status) 

2 ClearToEnterLight 

1 TurnOn (Request Action) 

2 TurnOff (Request Action) 

3 SafeBulkHeadClamp 

1 Extend 

2 Retract 

4 SafetyGate 

1 SenseSafe (Request Status) 

9 Documentation 



Control Bar Chart panel: Allows user to sequence the 

Requests of Control Assembly Instances via a control svstem-wide tool called a 
Control Bar Chart. 

_ Schematic Tool: Allows user to add the control system-wide schematic 
components such as factory sen/ices, rack layouts, ... and to connect the Control 
Assembly Instances electrically, pneumatically, and hydraulically via a control 
svstem-wide tool 

_ e.g., RSWire adapted to work off an integrated data model that allows a local 
(i.e., Control Assembly) schematic environment and a control system-wide tool that 
connects Control Assemblies and adds the additional schematics necessary to 
complete the Control System-wide design (e.g., Factory Services, Rack Layouts, ...) 
_ HMI Tool: Allows the user to combine the viewable entities in the control 
assemblies to layouts to monitor and control the process 
[00978] EC Simulation 

_ Visualization of the LL execution is facilitated through the use of RSLogix 
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(RSLadder is better) 

_ Visualization the current step(s) the machine is waiting on 

__ Visualization the "control process", i.e., animate the Bar Chart 

_ Use generated code via SoftLogix to animate in 3-D visualization of the workcell 

machines in order to simulate the process and the subsequent creation of the product 

[00979] Note: in EC all these simulations run off the same data model. 



EC Control System Implementation 

Bill of materials (from RS Wire Schematics) 

Make control system bill of materials and control system process 

available to the Machine and Process designers (i.e., export to CNext) 

Code generation Tool 

Diagnostics Generation Tool 

HMI (Visualization) Generation Tool 



EC Control System Maintenance 

Diagnostics 

Keeping control system design consistent with Product, 

Process, and Machine Design 

Password protect to provide restricted access to LL and the 

capability to record and changes that are made to the LL that must be 
reengineered into the design. 



Definition: a Control Assembly Component is a deployable 

control subsystem that exposes an interface (to Control System-wide tools) that is a 
composition of the following parts using a common object (or data) model and is 
easily configurable by setting properties. Figure 80 is a block diagram of a control 
assembly in accordance with a preferred embodiment. The boxed region designates 
the control assembly component which is a container. The control assembly 
component is a composition of a logic class 8010, a diagnostics class 8030, 
schematics class 8020, Human Machine Interface (HMI) class 8032 and a control 
model 8000. The control model 8000 which contains the common fields and 
methods (logic) for a control assembly class. The logic 8010 is a class that contains 
the fields and methods that are unique to the logic portions of a control assembly 
type. The diagnostics class 8030 is a class that contains the fields and methods that 
are unique to the diagnostics portions of a control assembly type. The schematics 
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class 8020 is a class that contains the fields and methods that are unique to the 
schematics portions of a control assembly type. The HMI class 8032 is a class that 
contains the fields and methods that are unique to the user interface portions of a 
control assembly type. 

[00980] The IRequest interface 8086 specifies the external behavior methods (logic) 

for controlling a controlled resource. For example, the message that invokes the logic for 
opening and closing a clamp. The IView interface 8080 specifies the external behavior 
methods (logic) for viewing schematics (electrical, hydraulic and pneumatic). The IBOM 
interface 8084 specifies the external behavior methods (logic) for retrieving the Bill-Of- 
Materials (BOM) for a control assembly component. The INetlist interface 8082 specifies the 
external behavior methods (logic) for retrieving the electrical, pneumatic and hydraulic 
connections between the control and mechanical devices within a control assembly 
component. 

[00981] The IRender interface 8070 specifies the external behavior method (logic) for 

retrieving viewable elements and their properties and generating a user interface. The 
IDocument interface 8060 specifies the external behavior method (logic) for producing 
documentation of the control assembly component. The IControl interface 8050 specifies the 
external behavior method (logic) for retrieving the resources that the control assembly 
component is capable of controlling. The Diagnostics interface 8040 specifies the external 
behavior method (logic) for selecting diagnostics that are instantiated for a control 
component. 

10 Control Components 

1 7 Definition: a control component is an entity that either 

sends a control signal, receives a control signal, or both sends and receives 
control signals. 

These components control the flow of the motive forces (electrical, 

pneumatic, and hydraulic) that cause mechanical operations to occur. 

18 Examples: solenoid valve (receives), proximity sensor 

(sends), Robot interface (both), PanelView interface (both), pushbutton 
(sends), indicator light (receives), motor controller (both), ... 

1 1 Mechanical Components 

19 Definition: a mechanical component that is required to 

implement or deploy the control subsystem (e.g., pneumatic hoses, check 
valves, ...) 
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12 Logic 

1 Definition: the logic specifies the control and fault states, the 

transitions between states that the control components can attain (i.e., the 
restricted state space of the control assembly), the controller outputs which 
produce the transitions, and inputs to the controller determine the current 
state. 

The following examples identify three types of logic groupings: input 

only, output only, and input/output. 

2 Examples: 

1 n-sensor PartPresent (input) 

1 States 

1 Part Absent 

2 Part Present 

3 Part out of position 

2 Transitions 

1 Part Absent => Part Present 

2 Part Present => Part out of position 

3 Part out of position => Part Absent 

4 Part Absent => Part Present 

5 Part Absent => Part out of position 

6 Part out of position => Part Present 

3 Outputs 

1 None 

4 Inputs 

1 all n off (Part Absent) 

2 all n on (Part Present) 

3 k of n on (k<n, k>0) (Part out of position) 

2 ClearToEnterLight (output) (e.g., single light also could be 

multiple lights) 
1 States 

1 LightOn 

2 LightOff 

2 Transitions 

1 LightOn => LightOff 

2 LightOff => LightOn 

3 Outputs 
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.1 LightOnSignal (LightOff => LightOn) 
_2 Not LightOnSignal (LightOn => LightOff) 



,3 SafeBulkHeadClamp (both) 

4 States 

1 Retracted 

2 Extended 

3 Between 



_5 Transitions 

1 Retracted => Between 

2 Between => Extended 

3 Extended => Between 

4 Between => Retracted 



cylinders) 



cylinders) 



_6 Outputs 

1 Extend (both valves opened = 4 outputs high) 

2 Retract (main valve closed = 2 outputs high) 

1 Inputs 

1 Retracted (retract proximity sensors on for all 



Extended (extend proximity sensors off for all 
Between ( one or more sets of proximity sensors 



both off) 



A 
5 



Fault 1 (one set of proximity sensors both on) 
Fault 2 (one or more of the set of sensors 
disagrees with the others for a nominally significant time period). 
1 3 Diagnostics 

1 Definition: Status-based diagnostics - specifies the step(s) 



that the machine is currently waiting to occur (if a fault occurs it specifies the 
step(s) that were waiting to occur at the time of the fault, i.e., the symptoms). 
Note: this information is available for both well behavior and fault 



behavior. 



2 Definition2: Causal model-based diagnostics - use a model of 



causal relationships to develop rules that relate machine status to root 
causes. 

3 Examples: 
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3 Consider that a human mechanic has incorrectly moved 

the mount location of a part present proximity sensor causing a 
misalignment. 

1 Status-based: determines that the machine is "waiting for 

part present sensor #2" (no automatic inference possible) 

4 Consider that the proximity sensor on a clamp cylinder 

has failed 

1 Status-based: determines that machine is "waiting for 

clamp cylinder 2504A" 
2 Causal model-based: logic infers that the extend 

proximity sensor on cylinder 2504A has failed, or that cylinder 2504A is 

stuck. 

14 Schematics 

1 Definition: a schematic is a representation of the electrical, 

pneumatic, and hydraulic interface to the control assembly. 

2 Examples: 

5 lelectrical 

6 Ipneumatic 

7 Ihydraulic 

8 

15 Visualization 

20 Definition: entities within the control assembly that are 

useful to portray textually or graphically. 
21 Examples: 

1 Control Components (textually or graphically) 
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Logic (graphically: LL, Function Blocks, Axis-like 



diagrams, state diagrams ...) what ever conveys the logic to the user. 

3 Diagnostics 

1 Status messages 

2 Causal messages 

4 Schematics 

1 Typed connections (electrical, pneumatic, network, ...) 

within Control Assembly and to and from the Control Assembly (i.e., 

the interface to the Control Assembly. 

2 Bill of Materials (to deploy the control assembly) 

3 ... 



_5 Controlled Resources 
_6 Requests 



_16 Controlled Resources 

22 Definition: properties of the resource controlled by the 



control assembly that place requirements (i.e., add constraints) on the 
structure of the assembly 

23 Example 

1 Clamp 1 

1 Safety constraint: if lose power clamp must fail open 

_1 7 Requests or Conditions 

24 Definition: request an operation (optionally with 



confirmation) or request a status of the external world (color code) 

1 Request Action Request Status 

2 Request Action 

3 Request Status 

4 Note: how to handle complicated actions (initialization, 

robot protocols, ...) 

25 Examples: 

1 PartPresent 

1 SensePart (Request Status) 

2 ClearToEnterLight 

1 TurnOn (Request Action) 

2 TurnOff (Request Action) 

3 SafeBulkHeadClamp 

1 Extend 
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2 Retract 

4 SafetyGate 

1 SenseSafe (Request Status) 

18 Documentation 



[00982] While the invention is described in terms of preferred embodiments in a 

specific system environment, those skilled in the art will recognize that the invention can be 
practiced, with modification, in other and different hardware and software environments 
within the spirit and scope of the appended claims. 

[00983] To apprize the public of the scope of this invention, the following claims are 

made: 
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